CN112905158A

CN112905158A - Marketing middle platform system based on hierarchical series technology

Info

Publication number: CN112905158A
Application number: CN202110119991.5A
Authority: CN
Inventors: 张永智; 徐克强; 欧平均
Original assignee: Guangzhou Yike Mingyi Information Technology Co ltd
Current assignee: Hangzhou Yike Information Technology Co ltd
Priority date: 2021-01-28
Filing date: 2021-01-28
Publication date: 2021-06-04
Anticipated expiration: 2041-01-28
Also published as: CN117193722A; CN117420986A; CN117193721A; CN117389527A; CN112905158B

Abstract

The invention discloses a marketing middling station system based on a hierarchical series technology, which specifically comprises the following steps: 101) marketing scene analysis step, 102) condition construction step, 103) rights and interests confirmation step; the invention discloses a marketing middle stage system based on a hierarchical series technology, which expresses complex and changeable marketing rules by abstracting a group of hierarchical item expression concepts in series, further realizes rule retrieval and verification based on hierarchical items, and applies the hierarchical item concepts to the definition of applicable conditions in the marketing middle stage.

Description

Marketing middle platform system based on hierarchical series technology

Technical Field

The invention relates to the technical field of software development, in particular to a marketing middlebox system based on a hierarchical series technology.

Background

Powerful marketing middleboxes need to be constructed in large-scale Saas software to support flexible and changeable scenes needed by merchants in online and offline integrated marketing. The software allows the merchant to establish custom rules aiming at different scenes and make different marketing preferential strategies. But offer strategies are diverse and lack a powerful expression, especially for the definition of applicability of "what conditions to meet" for enjoying an offer need. Naturally, other disadvantages are also present, such as difficulty in performing upgrade management of the system by gray scale hot deployment, difficulty in realizing distributed processing in transaction processing, extremely high requirements of the marketing system on printing statistics, difficulty in realizing rapid mobile terminal printing, and the like, and the problem of lack of a powerful expression mode is particularly prominent.

The technical scheme implementation of the marketing function in the existing software generally has two ideas:

one is a simple rule paradigm of dying for some specific marketing scenarios, for example, only a member of "a certain level" can be defined to enjoy discount for "a certain type or certain brand" of goods, such configuration is stored in a database table, fields such as members, goods conditions and the like are fixedly introduced, and names and types of the fields are all died; other similar marketing scenarios also require different tables and modules to implement. Most of the same software products on the market are at this level. The method is simple and quick, is easy to implement and understand, but obviously has extremely poor expansibility, and can not support the personalized requirement of rapid change of the Saas software in the scene of cross-industry and multi-tenant because the condition needs to be changed or more conditions are introduced, so that the modification or the rework is needed, the repeated work is more, and the method can not support the personalized requirement of rapid change of the Saas software in the scene of cross-industry and multi-tenant.

The other is based on some general rule engine, for example, the marketing rule is designed based on Drools rule engine; the rule engines are generally powerful and universal, and can support complex arithmetic, logic, comparison expressions, combinations thereof and operation priorities, thereby supporting flexible marketing condition definition and judgment logic. However, the rule engine itself is complex and requires scripting language support; accordingly, the configuration and use of application layer marketing rules are also very complicated, and the business is difficult to operate. In addition, although powerful, the rules engine has several disadvantages:

firstly, a simple query mode cannot be provided to quickly screen out the rule meeting the conditions from a plurality of rules, and whether the rule passes the screening can only be verified one by one.

Secondly, the rule engine can support expressions such as arithmetic and logic, but generally lacks a tree-like expression, for example, a national merchant discounts clothes for a winter style of a store in north China, a list is laid out in a store in a city under the north river province (north China), and is the store meet the regional condition? This requires the introduction of a hierarchical expression to determine whether members of the hierarchy have containment relationships. And at present, the consumption of computing resources is high when the regulatory engine runs, and under the high concurrency scene of Saas software, the real-time computing response is slow, so that the use of customers is influenced.

Disclosure of Invention

The invention overcomes the defects of the prior art and provides a marketing middling station system based on a hierarchical series technology.

The technical scheme of the invention is as follows:

a marketing center system based on a hierarchical series technology comprises a marketing condition module and a rights and interests module, and specifically comprises the following steps:

101) marketing scene analysis: analyzing a marketing condition module and a rights and interests module corresponding to the activities according to the corresponding activities and the link entries; the marketing condition module analyzes the applicable condition of the corresponding activity;

102) a condition building step: according to the application condition of the activity analyzed by the marketing condition module, confirming the quantity of the hierarchy items required by the activity, expressing the hierarchy in the hierarchy items by using the hierarchy, and realizing the calling of the marketing condition module of the activity by setting a corresponding interface;

103) and (4) right and interest confirmation step: the equity module gives corresponding discount equity or gives a proper gift package according to the activity condition set up by the marketing condition module in the step 102).

Further, the hierarchy sets at least one hierarchy from high to low inside the hierarchy item; each layer comprises at least one corresponding member, the members are discrete and hierarchical, and when the number of the members is multiple, a full range of special members are also set and represent all the members of the layer.

Furthermore, lower members in the same hierarchy item are positioned in the range of upper members; members between different hierarchy items are independent of each other.

Further, the data of the members of each hierarchy under the hierarchy item is stored in a relational table of the database, and the stored data structure type adopts a hierarchical relationship and/or a parent-child relationship.

Furthermore, the corresponding interface comprises a hierarchy item name, a hierarchy definition, a top-level member, a father member of a member, a lower-level member list of a member, and translation of a member, so that the member and the member relationship can be read conveniently; for example, the definition of java language is as follows:

where the reference to Member is defined as follows:

wherein the level reference is defined as follows:

further, the multiple hierarchy items in step 102) generate expressions representing different rules through the serial expressions.

Further, the relational table of the database comprises an index module, and the index module comprises a rule metadata definition table and a rule definition table;

a rule metadata definition table, wherein the hierarchy items corresponding to the corresponding marketing activities are not more than ten, each hierarchy item is stored, and if the hierarchy items do not reach ten, the rest hierarchy items are empty;

the rule definition table is used for storing specific rules, and comprises key fields, weight fields and related fields; the weight field is used for determining which rule is used by taking the weight field as priority when two or more rules simultaneously meet the activity condition; the member data stored in each hierarchy item is single or multiple, and commas are used for separating multiple member data.

The rule retrieval module extracts corresponding members as parameters according to each hierarchy item of the activity condition, retrieves the parameters from the set of parameter members in a rule definition table, and hits the rule if all hierarchy item members of a certain rule contain or are equal to the transmitted set of parameter members; after all matched rules are searched out, the business layer determines to select the rule with the highest weight according to the weight, or combines and uses all the rules, and finally carries out subsequent processing according to the preferential information defined in the interest module.

Further, the rule verification module is opposite to the rule retrieval module, and compares a preset group of parameter members with a specified one of the hierarchy item rules to verify whether the rule is met.

Compared with the prior art, the invention has the advantages that: the invention expresses complex and changeable marketing rules by abstracting a group of cascade hierarchical item expression concepts, thereby realizing the rule retrieval and verification based on hierarchical items. The hierarchy item concept is applied to the applicable condition definition in the marketing center.

The invention introduces the hierarchy concept, structurizes the complex information in the business field, simplifies the complex information, and is convenient for application developers and marketing rule configuration personnel to understand and operate.

Under the given conceptual model and interface definition constraint, an application developer can simply and consistently identify and rapidly develop specific hierarchical item objects; the hierarchy items can be uniformly registered in a hierarchy item warehouse after being defined, so that the hierarchy items can be reused in various service scenes. Finally, the development efficiency can be greatly improved, and the constantly changing marketing requirements can be well met.

Once the developers model and register the hierarchy items, the operators can independently configure the marketing campaign without relying on the developers. Operators can freely use different hierarchy item combinations according to needs, and freely combine a group of hierarchy item member values into a specific activity rule; in addition, because the hierarchy items naturally have the hierarchical characteristics, the introduction of the hierarchical expression can have more expressive force. The whole configuration process can be visualized and easily understood and operated.

The whole rule engine is light, and linear and millisecond response can be realized under the condition of ultrahigh concurrency of Saas software multi-tenancy by means of mature data retrieval technology of a relational database and a small amount of memory calculation.

Drawings

FIG. 1 is a schematic diagram of an automated packaging process for gray scale thermal deployment according to the present invention;

FIG. 2 is a schematic view of the gray scale hot deployment inspection updating process according to the present invention;

FIG. 3 is a schematic diagram illustrating an example of an optimal path for deploying grayscale heat according to the present invention;

FIG. 4 is a schematic diagram of an example of a gray scale thermal deployment shortest path selection according to the present invention;

FIG. 5 is a schematic diagram of hierarchical items within a marketing center of the present invention;

FIG. 6 is a schematic diagram of the hierarchy within the hierarchy item of the present invention;

FIG. 7 is a hierarchical view of the hierarchy of the present invention;

FIG. 8 is a schematic diagram of the parent-child relationship of the hierarchy of the present invention;

FIG. 9 is a flow chart of rule validation of the present invention;

FIG. 10 is a flow diagram of a distributed transaction process of the present invention;

FIG. 11 is a diagram of an example of a distributed transaction of the present invention.

Detailed Description

Reference will now be made in detail to the embodiments of the present invention, wherein like or similar reference numerals refer to like or similar elements or elements of similar function throughout. The embodiments described below with reference to the drawings are exemplary only, and are not intended as limitations on the present invention.

It will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the prior art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Reference numerals in the various embodiments are provided for steps of the description only and are not necessarily associated in a substantially sequential manner. Different steps in each embodiment can be combined in different sequences, so that the purpose of the invention is achieved.

The invention is further described with reference to the following figures and detailed description.

Example 1:

as shown in fig. 4 to 9, a marketing staging system based on hierarchical concatenation technology includes a marketing condition module and an interest module because activities and link entries are many, such as time-limited discount, holiday promotion, membership care, etc.; but as long as the types and numbers of the hierarchy items involved are the same, the marketing rules can be considered to be of the same type. As exemplified in the marketing rules in fig. 1, each has two marketing rules of three hierarchical terms. Therefore, when the hierarchy item is applied to the marketing medium discount strategy, the method specifically comprises the following steps:

101) marketing scene analysis: analyzing a marketing condition module and a rights and interests module corresponding to the activities according to the corresponding activities and the link entries; the marketing condition module analyzes the applicable condition of the corresponding activity.

102) A condition building step: according to the application condition of the activity analyzed by the marketing condition module, confirming the quantity of the hierarchy items required by the activity, wherein the specific hierarchy items can be represented by beginning with hier keywords; and expressing the hierarchy in the hierarchy item by using the hierarchy, and realizing the calling of the activity marketing condition module by setting a corresponding interface.

The hierarchy (level) is provided with at least one hierarchy from high to low from the inside of the hierarchy item. For example, a commodity level item may be a "primary category", "secondary category", "commodity" level from high to low; the regional hierarchy items comprise 'city', 'county', 'village and town', and the like from high to low as required; the time dimension may be from high to low in "year", "month" and "day", or may be in "year", "month" and "week" layers, as shown in fig. 2.

Each layer comprises at least one corresponding member, the members are discrete and hierarchical, and when the number of the members is multiple, a full range of special members are also set and represent all the members of the layer. Lower members in the same hierarchy item are positioned in the range of upper members; whereas an upper member comprises a lower member. Members between different hierarchy items are independent of each other. For example, at the regional level:

[ hierArea ] [ Ningbo City ]

[ hierArea ] [ Hangzhou City ]

[ hierArea ] [ Hangzhou City ] [ West lake region ]

In particular, a special member represents all value ranges of the layer, called all values for short, for example [ hierArea ] [ hangzhou city ] [ all ] represents all counties in hangzhou.

The data of the members of each hierarchy under the hierarchy item is stored in a relational table of the database, and the stored data structure type adopts a hierarchical relationship and/or a parent-child relationship. Taking the regional hierarchy as an example, the hierarchical relationship is shown in fig. 3, and each Level occupies one table field. The parent-child relationship is shown in fig. 4, the upper-lower Level relationship is expressed by fixing two fields code and pcode, and the parent-child relationship is a Level.

The corresponding interface comprises a hierarchy item name, a definition of a hierarchy, a top-level member, a father member of a certain member, a lower-level member list of a certain member and translation of a certain member, and the reading of the relationship between the members and the members is facilitated; the implementation level item model comprises a set of level and level interfaces and base classes, and when a new level item is identified and defined by the business layer, a new class can be rapidly implemented through secondary development. Specifically, the interface and base class of the hierarchy and hierarchy, which is defined as follows, takes java language as an example:

where the reference to Member is defined as follows:

wherein the level reference is defined as follows:

naturally, for two storage structure types of the hierarchy and the parent and the child, a corresponding toolkit can be packaged, so that the application layer can read the members and the relations from the table conveniently.

Step 102) the plurality of hierarchy items generate expressions representing different rules by concatenating the expressions. That is, for a marketing scenario, several hierarchical items are identified, each hierarchical item is assigned a membership value, and the membership values are combined together to form an expression. The hierarchical expression also defines a rule; expressions representing different rules may be generated by setting combinations of different member values.

For example, assume that a membership discount activity at a merchant involves the following three hierarchical items and their hierarchical definitions (the hierarchies are in order from high to low):

member (hierMember), there are two levels:

levelCustomer (Member level)

levelMember (Member individual)

The store (hierShop) has three levels:

levelArea (Large area)

levelCity (City)

levelShop

The commodity (hierSpu) has two levels:

levelBrand (trade brand)

levelSpu (commercial product)

According to the above hierarchy, there is the following set of rule definitions:

rule one, which indicates that diamond-level members can enjoy a discount when buying seven wolves and jagol brand clothing in a martial arts shop, the hierarchical expression is:

[ HierMember ], [ Diamond Member ], [ Hiershop ], [ Huadong region ], [ Hangzhou City ], [ Wulin shop ], { [ HierSpu ], [ seven wolf ], [ HierSpu ], [ Yagol ] }

Rule two: representing that the silver member can enjoy a discount when purchasing all brands of clothing in the martial store, the hierarchical expression is:

[ silver Member ], [ Hiershop ], [ Huadong region ], [ Hangzhou City ], [ Wulin shop ], [ HierSpu ], [ all brands ] }

The relational table of the database comprises an index module, and the index module comprises a rule metadata definition table and a rule definition table; the index module is established, so that the query is convenient and the efficiency is high.

And if the number of the hierarchy items corresponding to the corresponding marketing activities is not more than ten, storing each hierarchy item, and if the number of the hierarchy items is not more than ten, enabling the rest hierarchy items to be empty, namely enabling unused multi-definition hierarchy items to be empty.

The rule retrieval module extracts corresponding members as parameters according to each hierarchy item of the activity condition, retrieves in a rule definition table according to the group of parameter members, and hits the rule if all hierarchy item members of a certain rule contain or are equal to the group of parameter members; after all matched rules are searched out, the business layer determines to select the rule with the highest weight according to the weight, or combines and uses all the rules, and finally carries out subsequent processing according to the preferential information defined in the interest module.

The rules defined by the hierarchical item expressions are exemplified as follows, when a client places an order in a store, the software application layer can know who the client is (such as Zhang III, the member level is silver), which store places the order (such as Wulin shop) and what commodity is purchased (such as JB 002) in the current context scene, and the member parameter group is assembled according to the context information, and the structure is as follows:

[ HierMember ] - [ silver Member ] - [ ZhangIII ], [ HierShop ] - [ Huadong district ] - [ Hangzhou City ] - [ Wulin shop ], [ HierSpu ] - [ Jiumu ] - [ Niumu ] - [ Menu ] in summer in 2020 J.J. JB002 type in summer ] }

Using this set of parameter members to search in the "rule definition table" above, it is found that "rule two" described above is satisfied. Because the relational database is adopted, the algorithm of rule retrieval can be realized by directly using SQL statements, and the core segments of SQL statements are as follows:

if a comma is used to separate a plurality of member values stored in the hiern _ value field, it is also possible to indicate that one of the member values is satisfied. Taking Mysql database as an example, the find _ in _ set function of the database may be used instead of the expression, such as:

a rule verification module is also included, as shown in fig. 9, in contrast to the rule retrieval module, the rule verification module verifies whether the rule is satisfied by comparing a set of parameter members given in advance with a specified rule of a hierarchy item.

Example 2:

as shown in fig. 1 to 11, a new management system for marketing. The marketing system is constructed by a marketing condition module and an interest module, because activities and link entries are many, such as time-limited discount, holiday promotion, membership care and the like; but as long as the types and numbers of the hierarchy items involved are the same, the marketing rules can be considered to be of the same type. As exemplified in the marketing rules in fig. 1, each has two marketing rules of three hierarchical terms. Therefore, when the hierarchy item is applied to the marketing medium discount strategy, the method specifically comprises the following steps:

[ hierArea ] [ Ningbo City ]

[ hierArea ] [ Hangzhou City ]

[ hierArea ] [ Hangzhou City ] [ West lake region ]

The data of the members of each hierarchy under the hierarchy item is stored in a relational table of the database, and the stored data structure type adopts a hierarchical relationship and/or a parent-child relationship. Taking the regional hierarchy as an example, the hierarchical relationship is shown in fig. 3, and each Level occupies one table field. The parent-child relationship is shown in fig. 8, the upper-lower Level relationship is expressed by fixing two fields code and pcode, and the parent-child relationship is a Level.

where the reference to Member is defined as follows:

wherein the level reference is defined as follows:

member (hierMember), there are two levels:

levelCustomer (Member level)

levelMember (Member individual)

The store (hierShop) has three levels:

levelArea (Large area)

levelCity (City)

levelShop

The commodity (hierSpu) has two levels:

levelBrand (trade brand)

levelSpu (commercial product)

The system adopts an MQ-based distributed transaction method for transaction realization, and comprises a transaction message service module and a transaction message client plug-in module.

The transaction message service module comprises a message receiving module, a commit/rollback message module and a message checking module;

the received message is a received message interface provided by the transaction message service module and is used for being called by a transaction initiating end of the transaction message service module; after the transaction initiating terminal calls the message receiving interface, the transaction message service module caches message data to the cache server;

the transaction message service provides a commit/rollback message interface for the commit/rollback message to be called by a transaction initiating terminal of the transaction message service module; after the transaction initiating terminal calls the submission message interface, the transaction message service takes out the message data from the cache server, sends the data to the MQ server, and deletes the message data from the cache server after the transmission is successful; after the transaction initiating terminal calls the rollback message interface, the transaction message service deletes the message data from the cache server;

message checking processing, after a transaction initiating terminal calls a message receiving interface of a transaction message service, if a commit/rollback message interface of the transaction message is not called accidentally, message data cannot be forwarded and deleted, and in order to avoid data inconsistency caused by the situation, the transaction message service starts a timing task and regularly checks messages which are not forwarded and deleted in time; checking whether the transaction message which is not processed overtime exists, calling back an interface of a transaction initiating terminal, confirming whether the local transaction of the initiating terminal is successfully completed or not, submitting the message when the local transaction is successful, and rolling back the message when the local transaction is failed;

and the transaction message client plug-in module is used for realizing that the transaction message client plug-in is embedded into the transaction initiating terminal and the transaction receiving terminal.

The transaction message client plug-in module intercepts spring local transaction operation at a transaction initiating end, and performs transaction message related processing before and after the spring local transaction submitting or rolling back operation;

before committing the spring local transaction: the transaction initiating terminal calls a transaction message service receiving message interface in an asynchronous mode to realize that a transaction message client-side plug-in checks whether the receiving message interface is successfully called before spring local transaction is submitted, and normally submits the transaction when the spring local transaction is successfully submitted; if the interface call of the received message fails, rolling back the local transaction;

after spring local transaction commits: calling a transaction message service submission message interface;

after rolling back the spring local transaction: invoking a transaction message service rollback message interface.

The transaction message client plug-in module plays a role in assisting the receiving end to check whether the message is processed at the transaction receiving end, so that the message is prevented from being processed repeatedly; if the message can not be repeatedly consumed, when the transaction message client plug-in receives the message, the transaction message ID is written in the local table, and whether the transaction message ID exists is checked to ensure that the message is consumed only once.

As shown in fig. 11, taking the member charging and point sending service as an example:

the business requirement is that each member charges 1 yuan and sends 1 point. The user enters the recharging subsystem, and the message is accurately transmitted through receiving the message, submitting/rolling back the message and checking and processing the message, and the message is confirmed for multiple times to ensure the accuracy of the message.

The deployment and subsequent upgrade management of the system adopt a gray scale hot deployment mode based on real Native, and the gray scale hot deployment mode comprises a gitlab runner module, a web end module, a server end module and a client end module.

The gitlab runner module is used for executing a packaging task, deploying running service based on the platform through the open source code hosting platform, wherein the running service runs through corresponding execution task files, and the task files realize the executed tasks, including dependent downloading and packaging; and the task file is triggered through the corresponding external interface of the open source code hosting platform. Namely, gitlab is a free open source code hosting platform and can be deployed privately. runner is a kind of operating service based on gitlab, which executes tasks through the gitlab-ci.yml file in the project, which can write various execution tasks, such as npm package download corresponding dependency, package, etc. When runner is triggered, runner examines the [ gitlab-ci.yml file in the project, performing the relevant task. The runner trigger mode has various modes, such as monitoring code change of a certain branch, such as the trigger through a gitlab api, and generally triggering through the gitlab api.

The web end module is used for releasing gray levels, triggering the packing function of the gitlab runner module, uploading the package to the server after packing is finished, and completing one packing task; and after receiving the packed file, the server stores the version and the gray mode of the release into a database to finish one-time application release.

For example, there is a coupon function point, the function point code is in release/coupon branch, when the function point needs to be released, the release/coupon branch is selected on the web side, the release version is filled, the gray mode (in proportion: for example, 30%; in system version: for example, android 8, in network environment, etc.) is selected, and the release is clicked, at this time, the gitlab api https:// gitlab. example, com/api/v3/proj ects/1/pipeline is called. And triggering a configuration file, namely gitlab-ci.yml, in the gitlab runner inspection project, executing a packaging task, uploading the package to the server module after the packaging is finished, and finishing the packaging task once. And after receiving the packed file, the server module stores the version and the gray mode of the release into a database to finish one-time application release.

The server module is used for storing and issuing the packaged JavaScript for executing the task file; the server module comprises database tables and packages _ diff, wherein the packages table records the release of each version, and the information comprises package download links, version numbers, gray scale modes, whether diff packages exist or not, whether the diff packages can be downloaded or not and the like. The packages _ diff table records file information (if any) after diff issued each time, namely the differential file package. After receiving the package uploaded by the gitlab runner module, the server checks whether the package table has the package with the same version, and if not, records the corresponding information released at this time to the table packages; if the difference exists, generating differentiated content by using a text difference method, storing the differentiated content into an old package for replacement, and simultaneously recording the differentiated content into a packages _ diff table to complete a differentiation process.

When the request of the client module arrives (the request of the client module comprises information such as a version number, a system version, network conditions, regions and the like), the server module checks a packages table according to the version number carried by the request, and if the corresponding version number does not exist, a no-update package is returned; if the corresponding version number exists, whether a gray scale condition is met or not is checked (for example, the gray scale condition is that the gray scale condition is larger than 8, the gray scale condition is not met when the android system version carrying the request is 7, and the gray scale condition is met when the android system version is 9), no update package is returned when the gray scale condition is not met, whether a difference package exists or not is checked when the gray scale condition is met, a complete package download link is issued and exists, and the download link return is acquired from a table packages _ diff.

When the gray scale publishing from the web side module is suspended, the server side module marks whether the downloadable field of the publishing record corresponding to the packages table is negative, and at the moment, the client side module returns no update package when the request is reached.

The client module requests the interface to check and update every time the client module is started, the server module returns a related result according to the interface parameters, and the client module receives the returned result; if no update package exists, ending the process; if the update package exists, downloading the package; after the downloading is finished, judging whether the packet is a difference packet or not, if not, storing the packet to the local, marking the packet as current _ packet, and marking the running packet as previous _ packet; if the difference packet is the current packet, merging the content of the difference packet into the existing packet by using a text difference method, storing the content of the difference packet into the local, marking the stored packet as current _ packet, and marking the running packet as previous _ packet. The difference package is the downloaded package information which carries the unique identification information of whether the difference package is the downloaded package information.

And starting and acquiring the packet marked as current _ packet for running next time, if the current _ packet running for the first time is broken down, deleting the packet marked as current _ packet, and changing the packet marked as previous _ packet into current _ packet for running next time.

In conclusion, each real Native product line (such as chain diaries, laugh shop diaries, poke micro shops and the like) can be accessed to the system, when a new function point or bug needs to be issued, the system can be operated on, and one-time hot deployment can be rapidly completed. When a new function point is released, the user feeds back bug, and the influence on a large number of users can be reduced by suspending the release of the function.

Specifically, the text difference method has fewer processing steps, and is more newly added after deleted in processing than newly added; wherein the optimal selection is made by a shortest path search problem of the graph. Namely, the longest substrings with the same heads of the files are removed; and for the tail part, the longest substring is obtained by taking the shorter character string as a basis, then the longest substring is removed, and the rest part of the file is subjected to diff packet processing.

The text difference method comprises three operations of delete, insert and equal, wherein delete represents deletion operation, insert represents insertion operation and equal represents the same retention. The processing is carried out according to the principle that the processing steps are less, and the addition is carried out after the deletion in the processing, and the deletion is more after the addition. Specifically, if the source text is src ═ abcaba and the target text is dst ═ CBABAC, there are several ways from the source text to the target text:

the first method is as follows: -A, -B, C, -A, B, + A, B, A, + C (-for delete, + for insert, no sign added for equal);

the second method comprises the following steps: -a, + C, B, -C, A, B, -B, A, + C;

the third method comprises the following steps: + C, -A, B, -C, A, B, -B, -A, + C;

the first available set is represented as:

steps [ "deleteA", "deleteB", "equalC", "deleteA", "equalbb", "insertA", "equilib", "insertC" ], completing the conversion in nine Steps.

The second way can represent a set as:

steps [ "deleteA", "insert c", "equalB", "deleteC", "equalA", "equalB", "deleteB", "equalA", "insert c" ], and the conversion is completed in nine Steps.

The third way can represent the set as:

steps [ "insert c", "deleteA", "equal b", "deleteC", "equal a", "equal b", "deleteB", "deleteA", "insert a", "insert c" ], and the conversion is completed in ten Steps.

Obviously, the mode is more intuitive than the mode II, namely, the new addition after deletion is better than the deletion after the new addition, and the conversion steps are minimum. Thus conforming to the text differencing method. Wherein, determining as in the first and third modes, finding the shortest transformation step is obviously a typical shortest path search problem, still in the above transformation example, the structure is as shown in fig. 3, where the horizontal axis is src content, the vertical axis is dst content, each path from the top left corner to the bottom right corner in the figure represents a diff step, delete to the right, insert to the bottom, and equal to the diagonal (the original content remains unchanged).

The selection path is as follows:

(0,0)->(1,0)

(1,0)->(2,0)->(3,1)

(3,1)->(3,2)->(4,3)->(5,4)

(5,4)->(6,4)->(7,5)

(7,5)->(7,6)

the diff step represented by the path is: -A, -B, C, + B, A, B, -B, A, + C.

The src is successfully converted to dst by using the above path, but the path is not necessarily the path with the least steps, so that the path needs to be found by using dynamic planning and Myers algorithm thought, which is as follows:

first, parameters d and k are defined, d representing the length of the path and k representing the value of the current coordinate x-y. And defining an optimal coordinate, wherein the optimal coordinate represents the coordinate with the maximum x value under the condition that the d and k values are fixed. The larger x is, the more right is indicated, and more priority deletion operations are performed.

Specifically, starting from the coordinate (0,0), where d is 0 and k is 0, then d is gradually increased, and the corresponding optimal coordinate at each value of k is calculated. Since the diagonal does not affect the path length either to the right (x +1) or down (y +1) per step, when d is 1, there are only two values of k, either 1 or-1.

When d is 1 and k is 1, the optimal coordinates are (1, 0).

When d is 1 and k is-1, the optimal coordinates are (0, 1).

Since k is either 1 or-1 when d is 1, which means that one step is taken on the basis of d being 1 when d is 2, k has only three possible values, namely-2, 0 and 2.

When d is 2 and k is-2, the optimal coordinates are (2, 4).

When d is 2 and k is 0, the optimal coordinates are (2, 2).

When d is 2 and k is 2, the optimal coordinate is (3, 1).

And so on until we find a d and k value, reach the final target coordinate (7, 6). Establishing a horizontal axis representing d, a vertical axis representing k, and an optimal coordinate in the middle as shown in fig. 4, it can be known that when d is 5 and k is 1, the target coordinate (7,6) is reached, so that the shortest intuitive path is (0,0) - > (1,0) - > (3,1) - > (5,4) - > (7,5) - > (7,6), and the corresponding diff packet is as follows: -A, -B, C, + B, A, B, -B, A, + C. As described above, when d is 5, the optimal coordinates corresponding to all k must be known first, and when d is 4, the answer must be known first, and when d is 3, the shortest path can be obtained by analogy.

In the specific software gray level issuing process, because the packed js code character strings are thermally deployed, the two thermal deployments are largely performed, most codes are the same, and only a small part of codes are changed, a head-pinching and tail-removing operation is performed firstly, and the longest substring with the same head is removed; for the tail part, the longest substring is solved by taking the shorter character string as the basis, then the longest substring is removed, and the rest is subjected to a diff packet process, so that the diff packet process can be accelerated.

The hot-deploy js code as above is as follows:

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

and then the width is changed from the original 500 to 308 due to the change of the product requirement, and the changed js code is as follows:

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

because there are many repeated character strings in the beginning and end, in order to speed up the operation, the beginning and end are equal, and the corresponding process is equal. Assume that the head transform is denoted as Step1, the middle unequal transform is denoted as Step2, and the tail equal partial transform is denoted as Step 3.

Step1 equal (0,48), where 0,48 represents that the two code segments are equal from the starting position to the position where the length of the character string is 48.

Step2？

Step3 equal (51,300) where 51,300 indicates that the two pieces of code are equal from position 51 to the end (assuming a string length of 300).

Then now we can find Step2, i.e. the minimum transformation Step from src-500 to dst-308, and the minimum Step obtained using the above described dynamic programming concept is described as: -5, +3, 0, -0, + 8. Note that Step2 ═ delete (49, '5'), insert (49, '3'), equal (50,50, '0'), delete (51, '0'), insert (51, '8') ]. The whole transformation step is as follows: step ═ q (0,48), delete (49, '5'), insert (49, '3'), eq (50,50, '0'), delete (51, '0'), insert (51, '8'), equal (51,300) ]. Wherein, the first parameter of delete and insert represents the character position corresponding to the operation character string, and the second parameter represents the character of operation. The equal first and second parameters represent the starting and ending positions of the operator sub-string, and the third parameter is a specific operator character (which may not be present). The step of recording the Package diff table file is the change step, the client does not need to download the complete hot deployment code each time, the diff Package file is downloaded, and the complete code can be obtained according to the diff Package file.

Printing is taken as an essential function in the whole marketing, at present, the logic of analyzing data into printing instructions is realized at different terminals (iOS, Android and the like), the repeated work is caused, and the maintenance cost is very high, so that the system also integrates a visual editing method of a printing template for printing conveniently, particularly at a client use end, part of functions of the system are transplanted into a WeChat applet for facilitating the use and simplification of software, and the editing function of the visual template is realized by depending on the WeChat applet. Because the PC end has a complete printing implementation mode, and the mobile end has difficulty in realizing effective and rapid printing. The visual template editing function can also preset a large number of rich standard templates besides self-defining template editing. The technology of the visual editing function is realized by matching React Hooks with the assemblies of WeChat MovableArea and MovableView. The MovableArea and MovableView components provide basic moving capacity for materials, bidirectional binding of data is achieved through read useEffect Hook, views and data are bound, and a foundation is laid for subsequent actual printing. Whether bar code or plain text, support custom entry (static) and data reading (dynamic) ways, selectable as desired.

The template data can be stored at a printing center server after the template is edited, the front end only needs to transmit the template id and the corresponding goods data during subsequent printing, the printing center can perform pre-analysis on the template after receiving a request, and when a part needing to read the data is encountered, the goods data in the request can be read and filled to a corresponding position, and finally the goods data are analyzed into a printing instruction to be returned to the front end. After the front end receives the printing instruction, the instruction is directly transmitted to the printer for printing operation without any redundant action. The whole process is simple and rapid.

The terminal of the system is optimized by a network optimal line, when the terminal is started, a plurality of lines are firstly obtained from a service central point and cached in a local server to provide speed measurement service, all primary inlets are firstly detected, no line is selected, and then secondary is selected, wherein the primary difference of the secondary is bandwidth/stability/reliability. Static variables and guard times (4 seconds by 2 seconds to 8 seconds) were added at the end to prevent duplicate testing of the best line. The initiation of the line test adopts concurrent speed measurement, connection, reading and writing can be completed within 2 seconds, and the best line selection can be completed once in 4 seconds at worst. And when all speed measuring threads are finished and the optimal line is selected, the global variable can be updated at the fastest speed. Only after the foreground has the network without strength prompting, the optimal line detection is triggered, and the detection is asynchronous, so that the main service cannot be influenced. The method can be realized by a simple and conventional client selection algorithm without greatly increasing the burden of the existing Internet.

The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, several modifications and decorations can be made without departing from the spirit of the present invention, and these modifications and decorations should also be regarded as being within the scope of the present invention.

Claims

1. A marketing middle platform system based on a hierarchical series technology is characterized in that: the system comprises a marketing condition module and a rights and interests module, and specifically comprises the following steps:

2. The marketing staging system based on hierarchical tandem technology of claim 1, wherein: the hierarchy sets at least one hierarchy from high to low inside the hierarchy item; each layer comprises at least one corresponding member, the members are discrete and hierarchical, and when the number of the members is multiple, a full range of special members are also set and represent all the members of the layer.

3. The marketing staging system based on hierarchical tandem technology of claim 2, wherein: lower members in the same hierarchy item are positioned in the range of upper members; members between different hierarchy items are independent of each other.

4. The marketing staging system based on hierarchical tandem technology of claim 2, wherein: the data of the members of each hierarchy under the hierarchy item is stored in a relational table of the database, and the stored data structure type adopts a hierarchical relationship and/or a parent-child relationship.

5. The marketing staging system based on hierarchical tandem technology of claim 1, wherein: the corresponding interface comprises a hierarchy item name, a definition of a hierarchy, a top-level member, a father member of a certain member, a lower-level member list of a certain member and translation of a certain member, and the reading of the relationship between the members and the members is facilitated;

public interface IHierMetaInfo{

public String getHierName (); // defining hierarchy item names

public List < Level > getLevels (); // definition of acquisition hierarchy

public List < Member < T > > getTopLevelValues (); // obtaining top level Member

// obtaining the parent of a member

public Member<T>getParentMember(Member<T>curValue)；

// obtaining a lower member list of a certain member

public List<Member<T>>getSubLevelValues(Member<T>parentValue)；

// search Member value

public List<Member<T>>searchLevelValues(String searchToken)；

// translating for a member

public String getCaption(Member<T>code)；

}

Where the reference to Member is defined as follows:

public class Member<T>{

private T value; specific value

private String levelName; // to which hierarchy

}。

6. The marketing staging system based on hierarchical tandem technology of claim 1, wherein: step 102) the plurality of hierarchy items generate expressions representing different rules by concatenating the expressions.

7. The marketing staging system based on hierarchical tandem technology of claim 4, wherein: the relational table of the database comprises an index module, and the index module comprises a rule metadata definition table and a rule definition table;

8. The marketing staging system based on hierarchical tandem technology of claim 1, wherein: the rule retrieval module extracts corresponding members as parameters according to each hierarchy item of the activity condition, retrieves in a rule definition table according to the group of parameter members, and hits the rule if all hierarchy item members of a certain rule contain or are equal to the group of parameter members; after all matched rules are searched out, the business layer determines to select the rule with the highest weight according to the weight, or combines and uses all the rules, and finally carries out subsequent processing according to the preferential information defined in the interest module.

9. The marketing staging system based on hierarchical tandem technology of claim 8, wherein: the rule verification module is opposite to the rule retrieval module, compares a preset group of parameter members with a specified one of the hierarchy item rules to verify whether the rule is met.