CN117193722A - Hierarchical serial marketing center system based on MQ distributed transaction - Google Patents

Abstract

The invention discloses a hierarchical serial marketing center platform system based on MQ distributed transactions, which specifically comprises the following steps: 101 A marketing scene analysis step, 102) a condition construction step, 103) a rights and interests confirmation step; the invention expresses complex and changeable marketing rules by abstracting a group of serially connected hierarchical item expression concepts, thereby realizing rule retrieval and verification based on hierarchical items, and applying the hierarchical item concepts to the hierarchical serial marketing platform system based on MQ distributed transaction definition in marketing platform.

Description

Hierarchical serial marketing center system based on MQ distributed transaction

This patent is application number 202110119991.5, a divisional application of a marketing center system based on a hierarchical tandem technique

Technical Field

The invention relates to the technical field of software development, in particular to a hierarchical serial marketing center system based on MQ distributed transactions.

Background

A powerful marketing platform needs to be built in large-scale Saas software to support flexible and changeable scenes required by merchants in online and offline integrated marketing. The software should allow merchants to build custom rules for different scenarios and formulate different marketing preference policies. However, the preference policy is various, and particularly lack of powerful expression for the definition of applicability such as "what conditions are satisfied" for enjoying preference. Naturally, other disadvantages exist, such as difficulty in carrying out upgrading management of a gray scale heat deployment system, difficulty in realizing distributed processing in transaction processing, extremely high requirement on printing statistics by a marketing system, difficulty in realizing rapid mobile terminal printing at present, and lack of a powerful expression mode, and the problem is particularly prominent.

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

one is to simply write a dead rule paradigm for some specific marketing scenes, for example, only a certain level member can be defined to enjoy discounts for a certain class or brand of commodity, such configuration is stored in a database table, fields such as members, commodity conditions and the like can be fixedly introduced, and the naming and the types of the fields can be dead; other similar marketing scenarios also require different tables and modules to implement. Most of the same type of software products currently on the market are at this level. The method is simple and quick, easy to implement and easy to understand, but obviously has extremely poor expansibility, needs to be modified or reworked if the conditions are required to be changed or some conditions are introduced more, has more repeated work, and cannot support the personalized requirements of the Saas software for quick change in a multi-tenant scene in a cross-industry mode.

The other is to design marketing rules based on some general rule engine, for example, based on a Drools rule engine; such rule engines are generally very powerful and versatile, and can support complex arithmetic, logic, comparison expressions, and combinations and operational priorities thereof, thus enabling very flexible marketing condition definition and judgment logic. However, the rule engine itself is complex and requires scripting language support; correspondingly, the configuration and the use of the marketing rules of the application layer are very complex, and the merchants are difficult to get up. In addition, the rules engine, while powerful, has several drawbacks:

1. The simple query mode cannot be provided to rapidly screen out the rules meeting the conditions from the rules, and whether the rules pass the screening can only be verified one by one.

2. The rule engine can support arithmetic, logical, etc. expressions, but generally lacks a tree-like expression, for example, a national merchant discounts winter clothes with respect to a store in the north China, and then a city store located under the northwest province (the north China) spreads a sheet, and the store satisfies the regional condition? This requires the introduction of a hierarchical expression to determine whether the hierarchical members have containment relationships. Moreover, the current regulation engine consumes large computing resources when running, and the real-time computing response is slower in the high concurrency scene of Saas software, so that the use of clients is greatly affected.

Disclosure of Invention

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

The technical scheme of the invention is as follows:

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

101 Marketing scene analysis step): according to the corresponding activities and the link entries, a marketing condition module and a rights module corresponding to the activities are analyzed; the marketing condition module analyzes the applicable conditions of the corresponding activities;

102 A condition setting up step: confirming the number of hierarchy items required by the activity according to the applicable conditions of the activity analyzed by the marketing condition module, expressing the hierarchy in the hierarchy items by hierarchy, and realizing the call of the marketing condition module of the activity by setting a corresponding interface;

103 A rights and interests confirmation step: the equity module gives corresponding discount equity or gives an appropriate gift package according to the activity condition established by the marketing condition module in step 102).

Further, at least one hierarchy is set from high to low in the hierarchy item; each hierarchy includes at least one member, the members have discrete property and layering property, and when the number of the members is a plurality of members, a full-range special member is set, which represents all members of the hierarchy.

Further, lower members within the same hierarchical item are located within the upper member range; members between different hierarchical items are independent of each other.

Further, the data of the members of each hierarchy under the hierarchy item is stored in a relation table of the database, and the stored data structure type adopts a hierarchy relation and/or a father-son relation.

Further, the corresponding interfaces comprise a hierarchical item name, a hierarchical definition, a top-level member, a father member of a certain member, a lower member list of a certain member and a certain member for translation, so that the members and the membership can be conveniently read; taking java language as an example, the definition is as follows:

Wherein the reference to membrane is defined as follows:

wherein the level reference is defined as follows:

further, the plurality of hierarchy items in step 102) generate expressions representing different rules from the series 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;

the rule metadata definition table stores the corresponding marketing activities with no more than ten hierarchical items, and if the number of the hierarchical items is not ten, the rest hierarchical items are empty;

a rule definition table for storing specific rules including key fields, weight fields and related fields; wherein the weight field is used for deciding which rule to use by taking the weight field as priority when two or more rules simultaneously meet the activity condition; each hierarchical item stores member data in a single or a plurality of pieces, and comma separation is adopted when the plurality of pieces are used.

Further, the rule searching module extracts corresponding members as parameters according to each level item of the activity condition, searches the rule definition table according to the set of parameter members, and hits the rule if all the level item members of a certain rule contain or are equal to the set of parameter members; after all the matched rules are searched, the business layer decides to select the rule with the highest weight according to the weight, or combines all the rules to use, and finally, the business layer carries out subsequent processing according to the preferential information defined in the rights and interests module.

Further, the rule verification module is opposite to the rule retrieval module, and the rule verification module adopts a preset group of parameter members to compare with a specified level item rule to verify whether the rule is met.

Compared with the prior art, the invention has the advantages that: according to the method, the complex and changeable marketing rules are expressed by abstracting a group of serially connected hierarchical item expression concepts, so that rule retrieval and verification based on hierarchical items are realized. The hierarchical item concepts are applied to applicable condition definitions in the marketing platform.

The invention constructs the complex information in the business field by introducing the concept of the hierarchical item, simplifies the complex information, and is convenient for application developers and marketing rule configuration personnel to understand and operate.

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

Once the developer models and registers the hierarchy item, the operator may independently configure the marketing campaign independent of the developer. Operators can freely use different level item combinations as required to freely combine a group of level item member values into specific activity rules; in addition, because the hierarchical item has hierarchical characteristics naturally, the introduction of the hierarchical expression can have more expression power. The whole configuration process can be visualized visually, and is easy to understand and operate.

The whole rule engine is light, linear and millisecond response can be achieved under the condition of multi-tenant concurrency of Saas software 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 a gray scale hot deployment automated packaging process of the present invention;

FIG. 2 is a schematic diagram of a gray scale hot deployment inspection update flow according to the present invention;

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

FIG. 4 is a schematic diagram of an example gray scale heat deployment shortest path selection in accordance with the present invention;

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

FIG. 6 is a hierarchical schematic diagram of the interior of a hierarchical item of the present invention;

FIG. 7 is a schematic diagram of a hierarchical relationship of the hierarchy of the present invention;

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

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

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

FIG. 11 is a diagram of an example of distributed transactions according to the present invention.

Detailed Description

Embodiments of the present invention are described in detail below, wherein like or similar reference numerals refer to like or similar elements or elements of similar function throughout. The embodiments described below by referring to the drawings are exemplary only for explaining the present invention and not as a limitation of the present invention.

It will be understood by those skilled in the art that 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 unless defined otherwise. 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 referring to steps in the various embodiments are merely for convenience of description and do not have a substantial sequential relationship. Different steps in each specific embodiment can be combined in different sequences, so that the aim of the invention is fulfilled.

The invention is further described below with reference to the drawings and the detailed description.

Example 1:

as shown in fig. 4 to 9, a marketing center system based on a hierarchical tandem technology includes a marketing condition module and a equity module because activity and link entries are numerous, such as time-limited discounts, holiday promotion, membership care, etc.; but these marketing rules can be considered to be of the same class as long as the hierarchical items they relate to are of the same type and number. As exemplified in the marketing rules in fig. 1, each has two marketing rules of three hierarchical terms. Thus, when the hierarchical item is applied to the marketing center offer strategy, the method specifically comprises the following steps:

101 Marketing scene analysis step): according to the corresponding activities and the link entries, a marketing condition module and a rights module corresponding to the activities are analyzed; the marketing conditions module analyzes the applicable conditions of the corresponding activities.

102 A condition setting up step: confirming the number of hierarchy items required by the activity according to the applicable conditions of the activity analyzed by the marketing condition module, wherein the specific hierarchy items can be represented by the head of a hier keyword; the hierarchy in the hierarchy item is expressed by the hierarchy, and the call of the active marketing condition module is realized by setting a corresponding interface.

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

Each hierarchy includes at least one member, the members have discrete property and layering property, and when the number of the members is a plurality of members, a full-range special member is set, which represents all members of the hierarchy. Lower members within the same hierarchical item are located within the upper member range; the upper member includes the lower member. Members between different hierarchical items are independent of each other. For example, there are regions hierarchically:

[ hierArea ] [ Ningbo city ]

[ hierArea ] [ Hangzhou city ]

[ hierArea ]. Hangzhou city ] [ West lake area ]

A particular class of special members represents all value ranges for the layer, abbreviated as all values, e.g., [ hierArea ] [ hangzhou city ] [ all ] represents all counties under hangzhou.

103 A rights and interests confirmation step: the equity module gives corresponding discount equity or gives an appropriate gift package according to the activity condition established by the marketing condition module in step 102).

The data of the members of each hierarchy under the hierarchy item is stored in a relation table of the database, and the stored data structure type adopts a hierarchy relation and/or a father-son relation. Taking the regional hierarchy as an example, the hierarchical relationship is shown in fig. 3, and each Level occupies a table field. As shown in FIG. 4, the parent-child relationship is a hierarchical Level, and the fixed two field codes and pcode express the upper and lower relationships.

The corresponding interfaces comprise a hierarchical item name, a hierarchical definition, a top-level member, a father member of a certain member, a lower member list of a certain member and a certain member for translation, so that the members and the membership can be conveniently read; the service layer can develop and realize a new class for the second time when identifying and defining a new hierarchy item. The specific hierarchy and hierarchical interfaces and base classes, exemplified by java language, are defined as follows:

Wherein the reference to membrane is defined as follows:

wherein the level reference is defined as follows:

naturally, for both the hierarchy and parent-child storage structure types, corresponding toolkits can be packaged to facilitate the application layer to read membership and relationships from the table.

The multiple hierarchy items in step 102) generate expressions representing different rules from the series of expressions. That is, for a marketing scenario, several hierarchical items are identified, each hierarchical item is assigned a member value, and these member values are combined back and forth to form an expression. The hierarchical expression also defines a rule; expressions representing different rules may be generated by setting a combination of different member values.

For example, suppose that a membership discount campaign under a merchant involves the following three hierarchy items and their hierarchical definitions (hierarchy in order of high to low):

membership (hierMember) has two levels:

level customer (Member level)

level member (member person)

The store (hireshop) has three levels:

level area (Large area)

level City (City)

level shop

There are two levels of commodity (hierSpu):

level Brand (commercial brand)

levelSpu (commercial product)

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

Rule one, which indicates that diamond-class members can enjoy a discount when buying seven wolves and agoer brand clothing in a martial arts store, is expressed as:

{ [ hiermembrane ] [ diamond member ], [ hireshop ] [ Huadong district ] [ Hangzhou City ] [ martial arts ], { [ hierSpu ] [ seven wolves ], [ hierSpu ] [ jacale ] }

Rule II: indicating that the member of the silver class can enjoy a discount when buying all brands of clothing in the martial arts store, the hierarchical expression is:

{ [ hiermembrane ] [ silver Member ], [ hireshop ] [ Huadong district ] [ Hangzhou City ] [ martial arts ], [ hierSpu ] [ all brands ] }

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

And storing the corresponding hierarchy items of the corresponding marketing activities in the rule metadata definition table, wherein if the number of the hierarchy items is not more than ten, the remaining hierarchy items are empty, namely the unused multi-definition hierarchy items are empty.

A rule definition table for storing specific rules including key fields, weight fields and related fields; wherein the weight field is used for deciding which rule to use by taking the weight field as priority when two or more rules simultaneously meet the activity condition; each hierarchical item stores member data in a single or a plurality of pieces, and comma separation is adopted when the plurality of pieces are used.

The rule searching module extracts corresponding members as parameters according to each level item of the activity condition, searches in a rule definition table according to the set of parameter members, and hits the rule if all level item members of a rule contain or are equal to the set of parameter members; after all the matched rules are searched, the business layer decides to select the rule with the highest weight according to the weight, or combines all the rules to use, and finally, the business layer carries out subsequent processing according to the preferential information defined in the rights and interests module.

The rules defined by the hierarchical item expression are, for example, that when a customer places a list in a store, the software application layer can know "who the customer is in the current context scene" (for example, zhang three, the member level is silver), "which store to place a list in (for example, the martial arts store), and" what commodity is purchased "(for example, JB002 type), and the software application layer can assemble a member parameter set according to the context information, and the configuration is as follows:

{ [ hiermembrane ] [ silver Member ], [ hierShop ], [ Huadong district ], [ Hangzhou City ] [ Wulin store ], [ hierSpu ], [ JiuMu brand ] } [ summer leisure Men trousers JB002 version in 2020

Searching in the "rule definition table" using the parameter membership group may find that "rule two" described above is satisfied. Because of the relational database, the algorithm for rule retrieval can be realized by directly using SQL sentences, and the core fragments of the SQL sentences are as follows:

If the hiern_value field stores a plurality of member values separated by commas, it may be indicated 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, for example:

the rule verification module, as shown in fig. 9, is opposite to the rule retrieval module, and the rule verification module adopts a preset group of parameter members to compare with a specified level item rule to verify whether the rule is satisfied.

Example 2:

as shown in fig. 1 to 11, a novel management system applied to marketing. The system establishment for marketing comprises a marketing condition module and a rights module, because activities and link entries are numerous, such as time-limited discounts, holiday promotion, membership care and the like; but these marketing rules can be considered to be of the same class as long as the hierarchical items they relate to are of the same type and number. As exemplified in the marketing rules in fig. 1, each has two marketing rules of three hierarchical terms. Thus, when the hierarchical item is applied to the marketing center offer strategy, the method specifically comprises the following steps:

101 Marketing scene analysis step): according to the corresponding activities and the link entries, a marketing condition module and a rights module corresponding to the activities are analyzed; the marketing conditions module analyzes the applicable conditions of the corresponding activities.

102 A condition setting up step: confirming the number of hierarchy items required by the activity according to the applicable conditions of the activity analyzed by the marketing condition module, wherein the specific hierarchy items can be represented by the head of a hier keyword; the hierarchy in the hierarchy item is expressed by the hierarchy, and the call of the active marketing condition module is realized by setting a corresponding interface.

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

Each hierarchy includes at least one member, the members have discrete property and layering property, and when the number of the members is a plurality of members, a full-range special member is set, which represents all members of the hierarchy. Lower members within the same hierarchical item are located within the upper member range; the upper member includes the lower member. Members between different hierarchical items are independent of each other. For example, there are regions hierarchically:

[ hierArea ] [ Ningbo city ]

[ hierArea ] [ Hangzhou city ]

[ hierArea ]. Hangzhou city ] [ West lake area ]

A particular class of special members represents all value ranges for the layer, abbreviated as all values, e.g., [ hierArea ] [ hangzhou city ] [ all ] represents all counties under hangzhou.

103 A rights and interests confirmation step: the equity module gives corresponding discount equity or gives an appropriate gift package according to the activity condition established by the marketing condition module in step 102).

The data of the members of each hierarchy under the hierarchy item is stored in a relation table of the database, and the stored data structure type adopts a hierarchy relation and/or a father-son relation. Taking the regional hierarchy as an example, the hierarchical relationship is shown in fig. 3, and each Level occupies a table field. As shown in FIG. 8, the parent-child relationship is a hierarchical Level, and the fixed two field codes and pcode express the upper and lower relationships.

The corresponding interfaces comprise a hierarchical item name, a hierarchical definition, a top-level member, a father member of a certain member, a lower member list of a certain member and a certain member for translation, so that the members and the membership can be conveniently read; the service layer can develop and realize a new class for the second time when identifying and defining a new hierarchy item. The specific hierarchy and hierarchical interfaces and base classes, exemplified by java language, are defined as follows:

Wherein the reference to membrane is defined as follows:

wherein the level reference is defined as follows:

naturally, for both the hierarchy and parent-child storage structure types, corresponding toolkits can be packaged to facilitate the application layer to read membership and relationships from the table.

The multiple hierarchy items in step 102) generate expressions representing different rules from the series of expressions. That is, for a marketing scenario, several hierarchical items are identified, each hierarchical item is assigned a member value, and these member values are combined back and forth to form an expression. The hierarchical expression also defines a rule; expressions representing different rules may be generated by setting a combination of different member values.

For example, suppose that a membership discount campaign under a merchant involves the following three hierarchy items and their hierarchical definitions (hierarchy in order of high to low):

membership (hierMember) has two levels:

level customer (Member level)

level member (member person)

The store (hireshop) has three levels:

level area (Large area)

level City (City)

level shop

There are two levels of commodity (hierSpu):

level Brand (commercial brand)

levelSpu (commercial product)

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

Rule one, which indicates that diamond-class members can enjoy a discount when buying seven wolves and agoer brand clothing in a martial arts store, is expressed as:

{ [ hiermembrane ] [ diamond member ], [ hireshop ] [ Huadong district ] [ Hangzhou City ] [ martial arts ], { [ hierSpu ] [ seven wolves ], [ hierSpu ] [ jacale ] }

Rule II: indicating that the member of the silver class can enjoy a discount when buying all brands of clothing in the martial arts store, the hierarchical expression is:

{ [ hiermembrane ] [ silver Member ], [ hireshop ] [ Huadong district ] [ Hangzhou City ] [ martial arts ], [ hierSpu ] [ all brands ] }

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

And storing the corresponding hierarchy items of the corresponding marketing activities in the rule metadata definition table, wherein if the number of the hierarchy items is not more than ten, the remaining hierarchy items are empty, namely the unused multi-definition hierarchy items are empty.

A rule definition table for storing specific rules including key fields, weight fields and related fields; wherein the weight field is used for deciding which rule to use by taking the weight field as priority when two or more rules simultaneously meet the activity condition; each hierarchical item stores member data in a single or a plurality of pieces, and comma separation is adopted when the plurality of pieces are used.

The rule searching module extracts corresponding members as parameters according to each level item of the activity condition, searches in a rule definition table according to the set of parameter members, and hits the rule if all level item members of a rule contain or are equal to the set of parameter members; after all the matched rules are searched, the business layer decides to select the rule with the highest weight according to the weight, or combines all the rules to use, and finally, the business layer carries out subsequent processing according to the preferential information defined in the rights and interests module.

The rules defined by the hierarchical item expression are, for example, that when a customer places a list in a store, the software application layer can know "who the customer is in the current context scene" (for example, zhang three, the member level is silver), "which store to place a list in (for example, the martial arts store), and" what commodity is purchased "(for example, JB002 type), and the software application layer can assemble a member parameter set according to the context information, and the configuration is as follows:

{ [ hiermembrane ] [ silver Member ], [ hierShop ], [ Huadong district ], [ Hangzhou City ] [ Wulin store ], [ hierSpu ], [ JiuMu brand ] } [ summer leisure Men trousers JB002 version in 2020

Searching in the "rule definition table" using the parameter membership group may find that "rule two" described above is satisfied. Because of the relational database, the algorithm for rule retrieval can be realized by directly using SQL sentences, and the core fragments of the SQL sentences are as follows:

If the hiern_value field stores a plurality of member values separated by commas, it may be indicated 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, for example:

the rule verification module, as shown in fig. 9, is opposite to the rule retrieval module, and the rule verification module adopts a preset group of parameter members to compare with a specified level item rule to verify whether the rule is satisfied.

The system adopts a distributed transaction method based on MQ for the realization of the transaction, 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 submitting/rollback message processing module and a message checking processing 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 terminal of the transaction message service module; after the transaction initiating terminal calls the message receiving interface, the transaction message service module caches the message data to the cache server;

the submitting/rollback message is provided with a submitting/rollback message interface by a transaction message service for being called by a transaction initiating terminal of a transaction message service module; after the transaction initiating terminal calls the submitted message interface, the transaction message service takes out message data from the cache server, sends the data to the MQ server, and deletes the message data from the cache server after the data is successfully sent; after the transaction initiating terminal calls the rollback message interface, the transaction message service deletes message data from the cache server;

After the message checking processing, the transaction initiating terminal calls the message receiving interface of the transaction message service, if the submitting/rollback message interface of the transaction message is not called accidentally, the message data will not be forwarded and deleted, in order to avoid inconsistent data caused by the situation, the transaction message service starts a timing task, and the messages which are not forwarded and deleted in time are checked regularly; checking that the overtime unprocessed transaction information exists, calling back the transaction initiating terminal interface, confirming whether the local transaction of the initiating terminal is successfully completed, submitting the information when the local transaction is successfully completed, and rolling back the information 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 side plug-in module intercepts spring local transaction operation at a transaction initiating terminal and performs transaction message related processing before and after spring local transaction submission or rollback operation;

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

After the spring local transaction is submitted: invoking a transaction message service commit message interface;

after spring local transaction rollback: a transactional message service rollback message interface is invoked.

The business message client side plug-in module plays a role in assisting the receiving end to check whether the message is processed or not at the business receiving end, so that the repeated processing of the message is avoided; if the message cannot be repeatedly consumed, the transaction message client plug-in writes the transaction message ID in the local table when the message is received, and ensures that the message is consumed only once by checking whether the transaction message ID exists.

As shown in fig. 11, the member charging and point feeding service is taken as an example:

the service requirement is 1 element for each member charging, and 1 point is sent. The user enters the recharging subsystem, and the message is accurately transmitted through receiving the message, submitting/rolling back the message and checking the message, and the message is confirmed for a plurality of times, so that the accuracy of the information is ensured.

The deployment and subsequent upgrade management of the system adopts a gray scale heat deployment mode based on reactive, and the system comprises a gitlabrunner module, a web end module, a server end module and a client end module.

The system comprises a gitlabrunner module, an open source code hosting platform, a platform-based operation service, a task file, a platform-based operation service and a platform-based operation service, wherein the gitlabrunner module is used for executing a packing task, and the operation service operates through a corresponding execution task file to realize the execution task, and comprises the steps of dependent downloading and packing; and triggering the task file through the external interface corresponding to the open source code hosting platform. I.e. the gitlab is a free open source code hosting platform, which can be privately deployed. runner is an operating service based on the gitlab, which performs tasks via the in-project gitlab-ci.yml file, which can write various execution tasks, such as npm package download corresponding dependencies, packaging, etc. When the runner is triggered, the runner examines the. Gitlab-ci. Yml file in the project, performing the relevant task. There are various manners of triggering the runner, such as by listening for code changes of a branch, such as by using a gitlabapi.

The web end module is used for gray level release, triggering the packing function of the gitlabrunner module, uploading the package to the server after packing is finished, and completing a packing task; after receiving the package file, the server stores the released version and gray mode into the database to complete one-time application release.

For example, a coupon function point code is used for selecting a release/couple branch on a web end, filling in a release version, selecting a gray scale mode (according to proportion: such as 30 percent; according to system version: such as android8, according to network environment and the like) and clicking release when the function point code is released on the release/couple branch, and calling the gitlabapihttps:// gitlabsample. The method can trigger the gitlabrunner to check the configuration file in the project, execute the packing task, upload the package to the server module after the packing is finished, and complete the packing task once. After receiving the package file, the server module stores the released version and gray mode into the database to complete one-time application release.

The server side module is used for storing and issuing the packaged execution task file JavaScript; the server side module comprises a database table packages and packages_diff, wherein the packages record release of each version, and the information comprises a package download link, a version number, a gray mode, whether a diff package exists, whether the packages can be downloaded or not and the like. The packages_diff table records the file information (if any) after each diff issued, i.e., the differential file package. After receiving the package uploaded by the gitlabrunner module, the server checks whether the packages of the same version exist in the packages table, and if not, records the corresponding information released at the time to the packages of the table; if the content exists, generating differentiated content by using a text difference method, storing the differentiated content into an old package for replacement, and recording the old package into a packages_diff table to complete a differentiating process.

When the request of the client module arrives (the request of the client module comprises information such as version number, system version, network condition, region and the like), the server module checks the packages table according to the version number carried by the request, and if the corresponding version number does not exist, no update package is returned; if the corresponding version number exists, checking whether a gray condition is met (for example, the gray condition is that the android system version is greater than 8, the gray condition is not met when the android system version of the information carried by the request is 7, the gray condition is met when the android system version is 9), returning a no-update packet when the gray condition is not met, checking whether a difference packet exists, and if not, issuing a complete packet download link, and if so, acquiring the download link from the table packages_diff and returning.

When a certain gray level release is suspended from the web side module, the server side module marks whether a downloadable field of a release record corresponding to the packages table is NO, and when the client side module requests to touch, no update package is returned.

The client module requests the interface to check and update each time the client module is started, the server module returns a relevant result according to the interface parameters, and the client module takes the returned result; if no update package exists, ending the flow; if there is an update package, downloading the package; after the downloading is finished, judging whether the package is a difference package, if not, storing the package to the local, marking the package as current_package, and marking the running package as previous_package; if the packet is the difference 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 a local area, marking the stored packet as current_packet, and marking the running packet as previous_packet. The difference packet is downloaded packet information, and the downloaded packet information carries specific identification information of whether the difference packet is the difference packet or not.

And next time, starting to acquire the package operation marked as the current_package, deleting the package marked as the current_package if the current_package is crashed when the current_package is operated for the first time, and simultaneously changing the package marked as the previous_package into the current_package for next time starting operation.

In summary, each reactionary product line (such as a linked diary, a laughing diary, a merchant Liu Wei store, etc.) can be connected to the system according to the scheme, and when a new functional point or bug needs to be issued, the system according to the scheme can be operated, thereby rapidly completing one-time heat deployment. After the new function point is released, the user feeds back the bug, and the influence on a large number of users can be reduced by suspending the issuing function.

Specifically, the text difference method adopts fewer processing steps, and is added after being deleted in the processing and is more deleted than the new addition; wherein the optimal selection is performed by the shortest path search problem of the graph. Namely, the longest substring with the same head of the file is removed; and for the tail part, solving the longest substring based on the shorter character string, removing the longest substring, and performing diff packet processing on the rest part of the file.

The text difference method comprises three operations of delete, insert and equal, wherein delete represents a deletion operation, insert represents an insertion operation, and equal represents the same reservation. The method is processed by the principle that the processing steps are fewer, and more new deletion is added after the deletion is processed than the new deletion. Specifically, if the source text is src=abcbaba and the target text is dst=cbabac, there are various ways to change from the source text to the target text:

Mode one: -a, -B, C, -A, B, + A, B, A, +c (-delete, + insert), without the addition of a symbol equal);

mode two: -a, + C, B, -C, A, B, -B, A, +c;

mode three: +C, -A, B, -C, A, B, -B, -A, +A, +C;

mode one available set is represented as:

step= [ "deleteA", "deleteB", "equalC", "deleteA", "equalB", "insert a", "equalB", "equalA", "insert c" ], the conversion is completed in nine Steps.

Mode two may represent the set as:

step= [ "deleteA", "insert c", "equi", "deleteC", "equia", "equib", "deleteB", "equia", "insert c" ], the conversion is completed in nine Steps.

Mode three may represent the set as:

step= [ "insert c", "insert a", "equi b", "equi c", "equi b", "insert a", "insert c" ], ten Steps are taken to complete the conversion.

Obviously, the mode is more visual than the mode, namely the new mode is added after the deletion, the deletion is better than the deletion after the new mode, and the conversion step is the least. Thus conforming to the text difference method. In the above-described example, the configuration is shown in fig. 3, in which the horizontal axis is src content, the vertical axis is dst content, each path from the upper left corner to the lower right corner in the drawing represents a diff step, the delete step is shown to the right, the insert step is shown to the bottom, and the diagonal line represents equal (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 of path representation is: -A, -B, C, + B, A, B, -B, A, +C.

The src is successfully converted to dst by using the path, but not necessarily the path with the least steps, so the path needs to be found by using dynamic programming and Myers algorithm ideas, specifically as follows:

first, parameters d and k are defined, d representing the length of the path, k representing the value of the current coordinate x-y. An optimal coordinate is defined, and the optimal coordinate represents the coordinate with the largest x value under the condition that d and k values are fixed. The larger x indicates more to the right, more preferred deletion operations are performed.

Specifically, starting from the coordinates (0, 0), at this time, d=0, k=0, and then d is gradually increased, and the corresponding optimal coordinates at each k value are calculated. Since each step either right (x+1) or down (y+1), the diagonal does not affect the path length, k can only take two values, either 1 or-1, when d=1.

When d=1, k=1, the optimal coordinate is (1, 0).

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

Since k is either 1 or-1 when d=1, and represents one more step on the basis of d=1 when d=2, k has only three possible values, -2,0,2, respectively.

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

When d=2, k=0, the optimal coordinate is (2, 2).

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

And so on until we find a d and k value to reach the final target coordinates (7, 6). Establishing the horizontal axis as shown in fig. 4 to represent d, the vertical axis to represent k, and the middle to be the optimal coordinate, it is known that when d=5, k=1, the target coordinate (7, 6) is reached, and therefore 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=5, the optimal coordinates corresponding to all k must be known first, when d=4, the optimal coordinates corresponding to all k must be known, when d=4, the answer must be known first, d=3 must be solved, and so on, so that the shortest path can be obtained.

In the specific software gray level release process, because js code character strings packaged by hot deployment are largely the same in two times of hot deployment, and only a small part of codes are changed, a head pinching and tail removing operation is performed first, and the longest substring with the same head is removed; for the tail part, the longest substring is calculated based on the shorter character string, 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 last hot deployment js code is as follows:

yr＝v.create({app:{marginHorizontal:"auto",width:500}}),br＝vr；Un.registerComp onent("App",(function(){returnbr})),Un.runApplication

("App",{rootTag:document.getElementById("react-root")})}])；

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

yr＝v.create({app:{marginHorizontal:"auto",width:308}}),br＝vr；Un.registerComp onent("App",(function(){returnbr})),Un.runApplication

("App",{rootTag:document.getElementById("react-root")})}])；

since there are many repeated strings from head to tail, in order to accelerate the operation, the head and tail are equal, and the corresponding process is recorded as equivalent. Let the head transform be Step1, the middle unequal transform be Step2, and the tail equal partial transform be Step3.

Step1equal (0, 48). Wherein 0,48 represents that the two codes are equal from the start position to the position where the string length is 48.

Step2？

Step3equal (51,300) where 51,300 represents that the two codes are equal from position 51 to end (assuming string length 300).

Then Step2, the least transformation Step from src=500 to dst=308, is now found, and the least steps are described as using the dynamic programming concept described above: -5, +3, 0, -0, +8. Denoted Step2 = [ delete (49, '5'), insert (49, '3'), equal (50, '0'), delete (51, '0'), insert (51, '8') ]. The entire transformation step is as follows: step= [ equivalent (0, 48), delete (49, '5'), insert (49, '3'), equivalent (50, '0'), delete (51, '0'), insert (51, '8'), equivalent (51,300) ]. Wherein delete, insert the first parameter represents the character position corresponding to the operation string and the second parameter represents the character of the operation. The first and second parameters of the equation represent the start and end positions of the operation substring, and the third parameter is the specific operation character (which may not be present). The Packagediff table file records the change step, the client does not need to download the complete hot deployment code each time, downloads the diff package file, and can obtain the complete code according to the diff package file.

Printing is used as an indispensable function in the whole marketing, at present, logic for analyzing data into printing instructions is respectively realized at different terminals (iOS, android and the like), repeated work is caused, and the maintenance cost is high, so that the system is convenient to print, a visual editing method of a printing template is also integrated, particularly at a client use end, part of functions of the system are transplanted into a WeChat applet for convenient use and software simplification, and the visual template editing function is realized by depending on the WeChat applet. Because there is a complete print implementation on the PC side, it is difficult for the mobile side to implement efficient and fast printing. The visual template editing function can customize the editing template and presets a large number of rich standard templates. The technology of the visual editing function is realized through a ReactoHooks matching WeChat MovableArea, movableView component. The MovableArea, movableView component provides basic mobile capability for materials, and realizes bidirectional binding of data through reactivaffect hook, so that views and the data are bound, and a foundation is laid for subsequent actual printing. The bar code or the common text supports the mode of user-defined input (static) and data reading (dynamic), and can be selected according to the requirement.

After editing the template, the template data can be stored in a printing center server, the front end only needs to transmit the template id and corresponding goods data during subsequent printing, the printing center can pre-analyze the template after receiving the request, and when the part needing to read the data is encountered, the part needing to read the data can be read from the goods data in the request and filled in the corresponding position, and finally, the part is analyzed into a printing instruction and 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 also optimizes the network optimal line, when the terminal is started, a plurality of lines are firstly obtained from a service center point and cached in a local server to provide speed measurement service, all first-stage inlets are firstly detected, no line is selected, then two stages are selected, and the main difference between the two stages is bandwidth/stability/reliability. The addition of static variables and guard time (4 seconds 2=8 seconds) at the terminal prevents repeated measurements of the best line. The initiation of the line test adopts concurrent speed measurement, and can be completed in 2 seconds for connection, reading and writing, and the best line selection can be completed once in the worst 4 seconds. When waiting for all the speed measuring threads to finish, the best line is selected and then updated to the global variable at the fastest speed. Wherein this triggers the optimal line detection only after the network non-force prompt occurs in the foreground, and the detection is asynchronous, which does not affect the main service. The existing internet burden is not greatly increased, and the method can be realized by using a simple and conventional client selection algorithm.

The foregoing is merely a preferred embodiment of the present invention, and it should be noted that modifications and adaptations to those skilled in the art may be made without departing from the concept of the present invention, and such modifications and adaptations are intended to be comprehended within the scope of the present invention.

Claims (5)

1. A hierarchical serial marketing center system based on MQ distributed transactions, characterized in that: the method comprises a marketing condition module and a rights module, and specifically comprises the following steps:

101 Marketing scene analysis step): according to the corresponding activities and the link entries, a marketing condition module and a rights module corresponding to the activities are analyzed; the marketing condition module analyzes the applicable conditions of the corresponding activities;

102 A condition setting up step: confirming the number of hierarchy items required by the activity according to the applicable conditions of the activity analyzed by the marketing condition module, expressing the hierarchy in the hierarchy items by hierarchy, and realizing the call of the marketing condition module of the activity by setting a corresponding interface;

103 A rights and interests confirmation step: the equity module gives corresponding discount equity or gives a proper gift package according to the activity condition established by the marketing condition module in the step 102); wherein, the hierarchy sets at least one hierarchy from high to low from the interior of the hierarchy item; each hierarchy comprises at least one corresponding member, the members adopt discreteness and layering, and when the number of the members is a plurality of, a full-range special member is also set and represents all the members of the hierarchy;

The system also comprises message transaction processing, including a transaction message service module and a transaction message client plug-in module;

the transaction message service module comprises a message receiving module, a submitting/rollback message processing module and a message checking processing module; the submitting/rolling-back message is provided with a submitting/rolling-back message interface by the transaction message service, and is used for being called by a transaction initiating terminal of the transaction message service module; after the transaction initiating terminal calls the submitted message interface, the transaction message service takes out message data from the cache server, sends the data to the MQ server, and deletes the message data from the cache server after the data is successfully sent; after the transaction initiating terminal calls the rollback message interface, the transaction message service deletes message data from the cache server;

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.

2. A hierarchical tandem marketing center system based on MQ distributed transactions as set forth in claim 1, wherein: lower members within the same hierarchical item are located within the upper member range; members between different hierarchical items are independent of each other.

3. A hierarchical tandem marketing center system based on MQ distributed transactions as set forth in claim 1, wherein: the data of the members of each hierarchy under the hierarchy item is stored in a relation table of the database, and the stored data structure type adopts a hierarchy relation and/or a father-son relation.

4. A hierarchical tandem marketing center system based on MQ distributed transactions as set forth in claim 1, wherein: the corresponding interfaces comprise a hierarchical item name, a hierarchical definition, a top-level member, a father member of a certain member, a lower member list of a certain member and a certain member for translation, so that the members and the membership can be conveniently read.

5. A hierarchical tandem marketing center system based on MQ distributed transactions as set forth in claim 1, wherein: the transaction message client side plug-in module intercepts spring local transaction operation at a transaction initiating terminal and performs transaction message related processing before and after spring local transaction submission or rollback operation;

the business message client side plug-in module plays a role in assisting the receiving end to check whether the message is processed or not at the business receiving end, so that the repeated processing of the message is avoided; if the message cannot be repeatedly consumed, the transaction message client plug-in writes the transaction message ID in the local table when the message is received, and ensures that the message is consumed only once by checking whether the transaction message ID exists.