WO2020001391A1 - 菜单动态管理方法、服务器和系统 - Google Patents

菜单动态管理方法、服务器和系统 Download PDF

Info

Publication number
WO2020001391A1
WO2020001391A1 PCT/CN2019/092478 CN2019092478W WO2020001391A1 WO 2020001391 A1 WO2020001391 A1 WO 2020001391A1 CN 2019092478 W CN2019092478 W CN 2019092478W WO 2020001391 A1 WO2020001391 A1 WO 2020001391A1
Authority
WO
WIPO (PCT)
Prior art keywords
menu
message
change
display
change message
Prior art date
Application number
PCT/CN2019/092478
Other languages
English (en)
French (fr)
Inventor
黄媛媛
付迎春
刘学生
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to EP19825890.7A priority Critical patent/EP3812893A4/en
Priority to US17/055,123 priority patent/US11169863B2/en
Publication of WO2020001391A1 publication Critical patent/WO2020001391A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
    • G06F3/0482—Interaction with lists of selectable items, e.g. menus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G06F9/44526—Plug-ins; Add-ons
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services

Definitions

  • the present application relates to the field of computer network technology, and in particular, to a method for dynamically managing a menu, a server, a system, and a computer-readable storage medium.
  • a dynamically managed system such as a microservice architecture system
  • its functions are split into independent microservices, and microservices can run, deploy, upgrade, and uninstall independently.
  • the system of dynamic management usually requires that the menu can also change dynamically following the change of the function, that is, the menu of the function can be dynamically added or updated when the function is deployed, and the menu corresponding to the function can be dynamically uninstalled when the function is uninstalled.
  • independently deployed functions can independently provide service capabilities. These service capabilities can be flexibly combined to expose different function sets to different scenarios, and only provide menus within the function set.
  • the typical application scenario is a multi-tenant scenario.
  • the full set of functions is deployed in the background, and then these service capabilities are assembled according to the purchase of services by the tenant.
  • the only menus that can be seen on the tenant's portal are Corresponding menu of purchased features.
  • the need for dynamic management of menus can be divided into two levels: first, to implement dynamic menu management according to the installation and uninstallation of functions; second, to assemble the capabilities in the system into function sets according to needs, and different function sets Different portals are exposed, and the menus on the portals are also required to match the function set, which can flexibly provide the menu set corresponding to the function set.
  • the dynamic menu management method is to send a menu registration message to the menu management module when each independent function is deployed, or the menu management module actively collects menus from various functions.
  • the menu management module combines these menus and then The menu display module displays the menu.
  • the menu management is performed by a menu management module.
  • the menu management module is a central node for menu processing.
  • the menu management module may become a bottleneck. For example, if the module has a problem or is not deployed, the menu cannot be registered normally. , Merge, and display, rendering the entire system unusable and lacking robustness.
  • a dynamic menu management method, server, system and computer-readable storage medium proposed in this application are aimed at solving the problem of lack of robustness of the system when a single menu management module performs menu registration, merging, and display.
  • a method for dynamically managing a menu including:
  • the portal unit monitors the menu change message, analyzes the menu change information, and updates the menu displayed on the interface.
  • a server which includes a processor, a memory, and a data bus;
  • the data bus is used to implement connection and communication between the processor and the memory
  • the processor is configured to execute a memory model calculation program stored in a memory to implement the following steps:
  • the portal unit monitors the menu change message, analyzes the menu change information, and obtains a menu display file.
  • a menu dynamic management system includes at least one server and several clients.
  • the server is provided with several functional units and several portal units.
  • the client Display interfaces are provided corresponding to the portal units, and the following steps are implemented in the system:
  • a computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors. To implement the steps of the menu dynamic management method as described above.
  • the menu dynamic management method, server, system, and computer-readable storage medium provided by the embodiments of the present invention forward and temporarily store menu change messages through a message middleware cluster, and there is no need to have a special
  • the central node of the menu processing, the menu information that is not written and stored are all stored in the message middleware.
  • the menu message processing, storage, and consolidation can be performed.
  • the cluster deployment mode even if a message middleware instance is abnormal, it will not affect the menu registration and uninstallation in the system.
  • the system uses a decentralized architecture, and there is no dependency on the startup sequence of each module. Even if the menu change processing module and menu merge module are started after the menu is registered, the registered menu can be obtained after the startup.
  • the menu definition is more standardized and consistent, ensuring the correctness of menu registration and subsequent merge logic.
  • the existing menu set in the system is customized according to a subset of functions defined by the portal unit to make the menu processing more flexible. For all changes in functions, the menu can be modified flexibly to make the menu consistent with the function.
  • FIG. 1 is a flowchart of a method for dynamically managing a menu according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a second coverage level update processing method according to an embodiment of the present invention.
  • FIG. 3 is a flowchart of a third coverage level update processing method according to an embodiment of the present invention.
  • FIG. 4 is a block diagram of a server structure according to an embodiment of the present invention.
  • FIG. 5 is a structural block diagram of a menu dynamic management system according to an embodiment of the present invention.
  • FIG. 6 is a block diagram of a menu dynamic management system module division structure according to an embodiment of the present invention.
  • FIG. 7 is a block diagram of a workflow of a menu dynamic management method according to an embodiment of the present invention.
  • the method of menu dynamic management when each independent functional unit is deployed, send a menu registration message to the menu management module, or the menu management module actively collects menus from each functional unit, and the menu management module combines these menus. The menu is then displayed by the menu display module.
  • the above menu dynamic management scheme uses a menu management module as a system central node. The foregoing description has explained that the above menu dynamic management lacks robustness (robustness), and there is a risk of system paralysis when the central node fails. Due to the centralized architecture, there are requirements for the startup sequence of independent deployment functions: menu management and display are performed by a menu management module. To register menus for each independent function, the module needs to be started first, and other functions can be used for menus. registered.
  • an embodiment of the present invention provides a method for dynamically managing a menu, which mainly includes steps S101 to S103.
  • step S101 when the function on the independently deployed function unit is changed, a menu change message generated by the function change is collected.
  • the system consists of 1-n functional units that can be independently deployed (independently deployed functional units can be microservices or plug-ins).
  • a menu change message is triggered.
  • the menu change message includes menu registration messages and menu uninstall messages .
  • step S102 the menu change message is received through a message intermediate file deployed in a cluster mode, and the menu change message is broadcasted and notified.
  • the menu change information that is not written into the storage is stored in the message middleware, and all menu change messages in the system are broadcasted to consumers.
  • menu message processing can be performed, Warehousing, merging, etc .; the cluster deployment mode of message middleware, even if a certain message middleware instance is abnormal, it will not affect the menu registration and uninstallation in the system; in this embodiment, kafka is selected as the message middleware.
  • kafka is selected as the message middleware.
  • Messages will be persisted on the hard disk, and even if the message middleware is restarted, the messages will not be lost; menu change processing, merging, etc. can be handled by multiple portals separately, without relying on a centralized menu processing module. This makes the menu dynamic management scheme robust.
  • step S103 the menu change message is monitored at the portal unit, and the menu change information is analyzed and processed to update the menu displayed on the interface.
  • the message for menu change is when the function is uninstalled and deployed, corresponding to menu registration and menu deletion.
  • the analyzing and processing the menu change information includes:
  • Step S201 When the menu registration message is monitored, parse the menu information in the menu registration message, and add or modify a menu set;
  • Step S202 When the menu uninstall message is monitored, analyze the menu identification ID (abbreviation of identification) information in the menu uninstall message, and delete the menu corresponding to the menu identification ID in the menu set.
  • menu identification ID abbreviation of identification
  • the method further includes: creating a unified menu model, defining a menu for each functional unit separately according to the unified menu model, and generating a corresponding menu definition file.
  • a menu model definition structure table provided by an embodiment of the present invention.
  • the menu model includes:
  • ID The ID of the menu, which is the unique identification of the menu
  • name_zh Chinese name of the menu
  • name_en English name of the menu
  • PageID The function page ID corresponding to the menu
  • Parent The parent menu ID of the menu.
  • the menu is allowed to have a hierarchical relationship.
  • the child menu is used to associate the parent menu;
  • Order order. When there are multiple submenus under the same parent menu, use order to indicate the display order.
  • Group Grouping, multiple submenus under the same parent menu can be grouped, and the same group is grouped together;
  • Operation It is the authentication operation code corresponding to the menu. When the interface is displayed, it is judged whether the operation code has permission. If the operation code is displayed, there is no permission. The menu is deleted.
  • License It is the license authorization item corresponding to this menu. When the interface is displayed, it is judged whether this authorization item is authorized. If there is authorization, it is displayed. Without authorization, this menu is deleted.
  • menu model can be widely applied to all menu management scenarios, and is not limited to scenarios that require dynamic management of menus.
  • Other parts can be widely used in scenarios or areas where functions in the system can be independently installed, uninstalled, and upgraded. such as:
  • microservices can be independently deployed, uninstalled, and upgraded.
  • the dynamic management of the menu can adapt to microservices very well.
  • a system that uses a plug-in architecture for the functions in the system also has the same characteristics as the microservice architecture. Therefore, the dynamic menu management according to the present invention can very well adapt to the flexibility of the dynamic management system;
  • Persistence means saving or deleting menu messages and providing queries.
  • the method further includes:
  • Step S301 When the portal unit needs to provide a part of the function set, obtain the menu identification information corresponding to the display menu required by the portal unit and the menu set, and obtain the menu after the menu identification information and the menu set intersect. Merge collection
  • Step S302 Organize the menu merged set into a menu tree structure, convert the menu tree nodes according to the display format, and generate a menu on the display interface.
  • the menu tree structure is organized according to the configured parentID, the menus with the same parentID are placed on one layer, and the menus on the same layer are sorted according to the order configuration. If the menus on the same layer are the same, they are considered one Group, the menus of the same group are put together.
  • the menu tree nodes are converted according to the displayed format, and converted into the format required for the interface display. In this embodiment, it is converted into an html fragment that can be directly parsed by a browser.
  • the server 40 includes at least a processor 401, a memory 402, and a data bus 403.
  • the data bus 403 is used to implement connection and communication between the processor 401 and the memory 402.
  • the memory 402 can store at least one computer program, which can be read, compiled, and executed by the processor 401.
  • the memory 402 is used as a computer-readable storage medium, which stores a program for identifying a type of a downloaded file, and the program can be executed by the processor 401, so as to implement the following steps of a menu dynamic management method:
  • the portal unit monitors the menu change message, analyzes the menu change information, and obtains a menu display file.
  • an embodiment of the present invention further provides a menu dynamic management system.
  • the system includes at least one server 40 and several clients 50.
  • the server 40 is provided with several functional units and several portal units.
  • the client 50 is provided with a display interface corresponding to the portal unit, and the following steps are implemented in the system:
  • the system 40 can be divided into multiple functional modules, including a menu proxy module 41, a message middleware cluster 42, a menu change management module 43, a menu definition module 44, a menu storage module 45, and a menu merge module. 46 and menu display module 51.
  • the menu agent module 41 is provided in each functional unit in the server 40 and is configured to collect a menu change message generated when a function is changed on each independently deployed functional unit.
  • the menu agent module 41 is responsible for collecting the menu definition file of the unit, sending a registration message, and when the function is uninstalled, obtaining all the registered menu identifiers of the unit and sending Menu uninstall message.
  • the message middleware cluster 42 is configured to receive the menu change message through a message intermediate file deployed in a cluster mode, and broadcast notification of the menu change message.
  • the message middleware deployed in the cluster mode is responsible for receiving menu-related messages and notifying the message consumers who listen for menu changes.
  • a Kafka cluster is used.
  • Kafka is a high-throughput distributed publish and subscribe message system, and the received messages will be persisted to the local hard disk.
  • Kafka is used for message forwarding, so that there is no need for a central node dedicated to user menu processing in the entire system. Menu information that has not been written into the storage is saved on kafka. Once a unit that can perform menu processing is started or normally running, You can do menu message processing, warehousing, merging, etc.
  • the menu change management module 43 is provided in each portal unit, and is configured to monitor the menu change message and analyze and process the menu change information.
  • the menu change management module 43 is deployed on the portal unit. According to the needs of the system, there will be 1-n portal units.
  • the menu change management module 43 on these portal units is responsible for monitoring menu messages on the message middleware and persisting the menu. Processing, if the menu registration message is monitored, the menu information in the menu registration message will be parsed to add or modify the menu storage; if the menu uninstall message is monitored, the menu identification information in the menu uninstall message will be parsed, and the menu storage message will be deleted. Corresponds to the menu.
  • the menu definition module 44 is provided in each functional unit, and is used to separately define a menu of each functional unit according to a unified menu model, and generate a corresponding menu definition file.
  • One menu instance file can have 1-n menus, and the same independently deployed functional unit (can be a microservice, plug-in, etc.) can have more menu files. These files are in json format and are placed in a fixed folder of the microservice.
  • the menu storage module 45 is configured to use a distributed database or a distributed cache to perform persistent processing on the menu information corresponding to each functional unit to generate a menu set.
  • the menu merging module 46 detects whether the portal unit provides a part of a function set, and when only a part of functions are required, reads the menu identification information and the menu set that the portal unit needs to display.
  • a menu merged set is obtained after the menu sets are intersected; the menu merged sets are organized into a menu tree structure, and the menu tree nodes are converted according to the display format to generate a menu display file.
  • the menu merging module 46 is deployed on the portal unit and is responsible for reading menus from the menu storage and merging them. Before the merger, it will be determined whether the portal unit only needs to provide a set of functions. If so, the intersection of the menus required by the portal unit and the menus that already exist in the system will be obtained as the menu merged set.
  • the menu tree structure is organized according to the configured parent ID, the menus with the same parent ID are placed on one layer, and the menus on the same layer are sorted according to the order configuration. If the menus on the same layer are the same, they are considered as a group , The menus of the same group are put together. After the tree structure is generated, the menu tree nodes are converted according to the displayed format, and converted into the format required for interface display. In this embodiment, it is converted into an html fragment that can be directly parsed by a browser.
  • the menu display module 51 is provided on the client 50 and is used to update and display the function menu passed by each portal unit.
  • the client 50 may be an application program such as a browser, and is integrated and installed on a mobile terminal product.
  • the system consists of 1-n functional units that can be independently deployed (independently deployed functional units can be microservices or plug-ins).
  • Each independently deployed functional unit has a menu definition module and a menu proxy module, which is responsible for the menus of this unit. Definition and registration; message middleware is responsible for message passing in the system, deployed in a cluster mode, and is inherently robust; 1-n portal units (a type of independent deployment unit used to showcase system entrances) are deployed in the system, these The portal unit includes a menu change processing module and a menu merge module, which are responsible for the integration of the menu; a menu storage module is responsible for the persistence (store or delete) of the menu; a menu display module is responsible for the menu display.
  • the above dynamic menu processing system is a decentralized architecture. There is no need for a centralized menu processing module in the system to perform menu change monitoring, menu change processing, and menu merge processing. There is also no limitation on the startup sequence of each module. Even if the menu change processing module and menu merge module are started after the menu is registered, the registered menu can be obtained after the startup.
  • An embodiment of the present invention provides a computer-readable storage medium.
  • the computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the menu dynamics as described above. Steps of the management approach.
  • Step S601 determining whether the function is currently deployed or uninstalled
  • step S602 the uninstaller obtains the menu identifier related to the microservice, and sends a menu uninstall message to the message middleware (in this embodiment, the message middleware kafka is used); or in step S603, the deployment searches for the menu under the specified folder of the microservice File, perform file analysis, and send the parsed information to the menu registration message to the message middleware;
  • Step S604 the menu proxy module listens to the menu change message of the message middleware, and reads the message;
  • Step S605 determine whether it is a menu registration message or a menu uninstall message
  • Step S606 if it is a menu uninstall message, remove the menu identifier to be deleted, and delete the corresponding menu in storage; (the storage device used in this embodiment is a PostGre distributed cache); step S607, if it is a menu registration message, remove it Check the menu contents and store the checked menu information;
  • Step S608 Read all the menus in the storage
  • step S609 it is determined whether menu customization is required (in a scenario where the portal unit only needs to display a part of the function set, the menu to be displayed is not the full set);
  • Step S610 if the menu customization is not required, obtain the intersection of the menu identifier to be displayed in the portal unit and all the menus as the menu merged set to be merged;
  • Step S611 Deduplicate the menu merged set, organize it into an ordered menu tree structure according to the definition of the hierarchical relationship, and then convert it into a menu structure that can be directly displayed according to the needs of the display, and persist it into a menu display file; (In this embodiment, it is converted into an html fragment that can be displayed directly in the browser.)
  • Step S612 Display the converted menu display file.
  • the browser initiates access to the merged menu file, reads the menu file to the browser, and loads it into the page).
  • the menu dynamic management method, system, and computer-readable storage medium provided by the embodiments of the present invention forward and temporarily store menu change messages through a message middleware cluster, and there is no need to have a dedicated menu processing method.
  • the menu information that is not written to the storage is stored in the message middleware.
  • menu message processing, storage, and consolidation can be performed; cluster deployment of message middleware Mode, even if a message middleware instance is abnormal, it will not affect the menu registration and uninstallation in the system.
  • the system adopts a decentralized architecture, and there is no dependency on the startup sequence of each module. Even if the menu change processing module and menu merge module are started after the menu is registered, the registered menu can be obtained after the startup.
  • the menu definition is more standardized and consistent, ensuring the correctness of menu registration and subsequent merge logic.
  • the existing menu set in the system is customized according to a subset of functions defined by the portal unit to make the menu processing more flexible. For all changes in functions, the menu can be modified flexibly to make the menu consistent with the function.
  • Such software may be distributed on computer-readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media).
  • computer storage medium includes both volatile and nonvolatile implementations in any method or technology used to store information such as computer-readable instructions, data structures, program modules or other data.
  • Removable, removable and non-removable media Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or Any other medium used to store desired information and which can be accessed by a computer.
  • a communication medium typically contains computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and may include any information delivery medium .
  • sequence numbers of the foregoing embodiments of the present invention are merely for description, and do not represent the superiority or inferiority of the embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Multimedia (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

一种菜单动态管理方法、服务器和系统，该方法包括：采集各个独立部署功能单元上功能变化时生成的菜单变化消息；通过集群方式部署的消息中间文件接收菜单变化消息，并对菜单变化消息进行广播通知；在门户单元监听菜单变化消息，并对菜单变化信息进行解析处理，更新界面显示的菜单。本发明的实施例通过消息中间件集群对菜单变化消息的转发和暂存，消息中间件的集群部署模式，从而形成了去中心化架构，各个功能模块的启动顺序上相互独立，使得系统更加具有健壮性。

Description

菜单动态管理方法、服务器和系统
本申请要求享有2018年6月25日提交的名称为“菜单动态管理方法、服务器、系统和计算机可读存储介质”的中国专利申请CN201810665814.5的优先权，其全部内容通过引用并入本文中。
技术领域
本申请涉及计算机网络技术领域，尤其涉及一种菜单动态管理方法、服务器、系统和计算机可读存储介质。
背景技术
在动态管理的系统中，比如微服务架构的系统，其功能拆分为独立的微服务，微服务可以独立运行、部署、升级、卸载。动态管理的系统通常要求菜单也能够跟随功能的变化动态改变，即功能部署时能够动态增加或更新该功能的菜单，功能卸载时能够动态卸载该功能对应的菜单。另外，独立部署的功能可以独立提供服务能力，这些服务能力可以灵活组合，对不同的场景暴露不同的功能集合，只提供在功能集合内的菜单。典型的应用场景是多租户场景，多租户场景下，后台部署的是功能全集，然后根据租户对服务的购买情况，对这些服务能力进行组装，在这个租户的门户上所能看到的菜单只有已经购买的功能的对应菜单。对菜单进行动态管理的需求，可以分为两个层次：第一，根据功能的安装卸载情况，实现动态的菜单管理；第二，根据需要把系统中的能力组装成功能集，不同的功能集暴露不同的门户，门户上的菜单也要求和功能集匹配，能够灵活的提供与功能集对应的菜单集合。
在一些情形下的动态菜单管理方法是当各个独立功能部署时，向菜单管理模块发送菜单注册消息，或者是菜单管理模块主动向各个功能收集菜单，菜单管理模块对这些菜单进行合并处理，然后由菜单显示模块对菜单进行展示。但是，菜单管理是由一个菜单管理模块来负责，菜单管理模块是专门用于菜单处理的中心节点，菜单管理模块可能成为瓶颈，比如该模块自身存在问题或者没有部署时，会导致菜单无法正常注册、合并和显示，导致整个系统不可用，从而缺乏健壮性。
发明内容
本申请提出的一种菜单动态管理方法、服务器、系统和计算机可读存储介质，旨在解决单一菜单管理模块进行菜单注册、合并和显示时，系统缺乏健壮性的问题。
为实现上述目的，根据本发明实施例的第一个方面，提供了一种菜单动态管理方法，包括：
当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息；
通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知；
在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，更新界面显示的菜单。
根据本发明实施例的第二个方面，提供了一种服务器，具有包括处理器、存储器及数据总线；
所述数据总线用于实现处理器和存储器之间的连接通信；
所述处理器用于执行存储器中存储的内存模型计算程序，以实现以下步骤：
当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息；
通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知；
在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，获得菜单显示文件。
根据本发明实施例的第三个方面，提供了一种菜单动态管理系统，所述系统包括至少一服务器以及若干客户端，所述服务器中设置有若干功能单元和若干门户单元，所述客户端对应所述门户单元分别设置有显示界面；在所述系统中实现以下步骤：
当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息；
通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知；
在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，获得菜单 显示文件；
将所述菜单显示文件发送到对应的显示界面，更新所述显示界面的菜单。
根据本发明实施例的第四个方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，一个或者多个程序可被一个或者多个处理器执行，以实现如上述菜单动态管理方法的步骤。
根据以上技术方案，可知本发明实施例提供的菜单动态管理方法、服务器、系统和计算机可读存储介质，通过消息中间件集群对菜单变化消息的转发和暂存，不再需要有一个专门用于菜单处理的中心节点，没有写入存储的菜单信息都保存在消息中间件上，一旦有可以进行菜单处理的单元启动或正常运行，就可以进行菜单消息处理、存储、合并等；消息中间件的集群部署模式，即使某个消息中间件实例不正常，也不会影响系统中的菜单注册、卸载。系统采用了去中心化架构，在各个模块的启动顺序上没有依赖关系，菜单变化处理模块、菜单合并模块即使在菜单注册之后再启动，也能在启动之后获取到已经注册的菜单。
另外，通过创建菜单统一模型，使得菜单定义更加规范、一致，保证菜单注册及后续合并逻辑的正确性。菜单合并时，根据所在门户单元定义的功能子集，对系统中现有的菜单集合进行定制，使菜单处理更加灵活。功能的所有变化，都可以灵活的进行菜单的修改，使得菜单与功能一致。
附图说明
图1是根据本发明实施例的一种菜单动态管理方法流程框图；
图2是根据本发明实施例的第二种覆盖级别更新处理方法流程框图；
图3是根据本发明实施例的第三种覆盖级别更新处理方法流程框图；
图4是本发明实施例的一种服务器结构框图；
图5是根据本发明实施例的一种菜单动态管理系统结构框图；
图6是根据本发明实施例的一种菜单动态管理系统模块划分结构框图；
图7是根据本发明实施例的菜单动态管理方法工作流程框图；
本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身没有特有的意义。因此，“模块”、“部件”或“单元”可以混合地使用。
在一些情况下的菜单动态管理方法，当各个独立功能单元部署时，向菜单管理模块发送菜单注册消息，或者是菜单管理模块主动向各个功能单元收集菜单，菜单管理模块对这些菜单进行合并处理，然后由菜单显示模块对菜单进行展示。上述菜单动态管理方案是以菜单管理模块作为系统中心节点，前述已经说明上述菜单动态管理放哪缺乏健壮性(鲁棒性)，存在中心节点故障时系统瘫痪的风险。由于采用中心化架构，对独立部署功能的启动次序有要求：菜单管理和展示都是由一个菜单管理模块来负责，各个独立功能要进行菜单注册，就需要该模块先启动，其他功能才能进行菜单注册。
基于上述技术方案的缺陷，具体提出了以下实施例。
实施例1
如图1所示，本发明实施例提供了一种菜单动态管理方法，主要包括步骤S101至步骤S103。
在步骤S101中、当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息。
通常系统由1-n个可以独立部署功能单元构成(独立部署功能单元可以是微服务或者插件)，当功能卸载或者部署时，触发生成菜单变化消息，菜单变化消息包括菜单注册消息和菜单卸载消息。
在步骤S102中、通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知。
没有写入存储的菜单变化信息都保存在消息中间件上，对系统中所有的菜单变化消息消费者进行广播通知，一旦有可以进行菜单处理的单元启动或正常运行，就可以进行菜单消息处理、入库、合并等；消息中间件的集群部署模式，即使某个消息中间件实例不正常，也不会影响系统中的菜单注册、卸载；本实施例选用kafka作为消息中间件，kafka接收 到的消息会在硬盘持久化，即使消息中间件整个重启，消息也不会丢失；菜单的变动处理、合并等，可以由多个门户来分别处理，不会依赖一个集中的菜单处理模块。从而使得菜单动态管理方案具有健壮性。
在步骤S103中、在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，更新界面显示的菜单。
针对菜单变化消息是在功能卸载和部署时，对应的是菜单注册和菜单删除。具体的，如图2所示，所述对所述菜单变化信息进行解析处理包括：
步骤S201、当监听到所述菜单注册消息时，解析该菜单注册消息中的菜单信息，新增或修改菜单集合；
步骤S202、当监听到所述菜单卸载消息时，解析该菜单卸载消息中的菜单标识ID(identification的缩写)信息，删除菜单集合中的与菜单标识ID对应的菜单。
其中，所述采集功能变化生成的菜单变化消息之前，所述方法还包括：创建一统一菜单模型，根据所述统一菜单模型分别定义每一功能单元的菜单，并生成对应的菜单定义文件。
表1 菜单模型定义结构表
Figure PCTCN2019092478-appb-000001
如表1所示，本发明实施例提供的一种菜单模型定义结构表，具体的，该菜单模型包括：
ID：菜单的标识，是菜单的唯一标示；
Name:
name_zh:菜单中文名；
name_en:菜单英文名；
Page ID：菜单对应的功能页面标识；
Position:
Parent：菜单的父亲菜单标识，菜单是允许有层级关系的，这里用子菜单关联父菜单；
Order：顺序，同一个父菜单下有多个子菜单时，用order表示显示顺序；
Group:分组，同一个父菜单下多个子菜单可以分组，group相同的排在一起；
display_attr:
icon:菜单图标
Display:是否显示，false则菜单隐藏；
right:
Operation:为菜单对应的鉴权操作码，在界面显示时，判断此操作码是否有权限，有权限则显示，无权限，该菜单删除；
License：为该菜单对应的license授权项，在界面显示时，判断此授权项是否有授权，有授权则显示，无授权，该菜单删除。
上述菜单模型的定义可以广泛应用于所有的菜单管理场景，不限于需要动态管理菜单的场景。其他部分可以广泛用于系统中的功能可以独立安装、卸载、升级的场景或领域。比如：
(1)采用微服务架构的系统，由于功能都是以微服务的方式独立提供，微服务可以独立部署、卸载、升级，在这种场景下，菜单的动态管理能够非常好的适配微服务架构的灵活性；
(2)对系统中的功能采用插件架构的系统，也存在和微服务架构相同的特点，因此，本发明所述的菜单动态管理可以非常好的适配动态管理系统的灵活性；
(3)分布式系统，系统中的功能分布式、独立部署，在这种场景下，菜单的动态管理能够非常好的适配分布式系统的灵活性。
其中，所述当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息之前，利用分布式数据库或分布式缓存对每一功能单元对应的菜单信息进行持久化处理，生成菜单集合。持久化就是对菜单消息进行保存或者删除，以及提供查询。
其中，如图3所示，所述在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，更新界面显示的菜单之后，所述方法还包括：
步骤S301、当所述门户单元需要提供部分功能集合时，获取所述门户单元所需要展示菜单对应的菜单标识信息与所述菜单集合，所述菜单标识信息和所述菜单集合取交集后 得到菜单合并集合；
步骤S302、将所述菜单合并集合组织形成菜单树结构，按照显示格式对菜单树节点进行转换，在显示界面生成菜单。
具体的，合并时，根据配置的parentID，来组织菜单树结构，把parentID相同的菜单放到一层，并且根据order配置进行同一层的菜单排序，同层的菜单如果group相同，则认为是一组，同一组的菜单放到一起。菜单树结构生成之后，再按照显示的格式，对菜单树节点进行转换，转换为界面显示需要的格式。本实施例中转换为浏览器可以直接解析的html片段。
实施例2
本发明实施例提供了一种服务器，具体地，如图4所示，所述服务器40至少包括处理器401、存储器402以及数据总线403。数据总线403用于实现处理器401和存储器402之间的连接通信，存储器402作为一种计算机可读存储介质，可以存储至少一个计算机程序，这些计算机程序可供处理器401读取、编译并执行，从而实现对应的处理流程。在本实施例中，存储器402作为一种计算机可读存储介质，其中存储有识别下载文件类型程序，该程序可供处理器401执行，从而实现如下的菜单动态管理方法的步骤：
当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息；
通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知；
在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，获得菜单显示文件。
实施例3
如图5所示，本发明实施例还提供了一种菜单动态管理系统，所述系统包括至少一服务器40以及若干客户端50，所述服务器40中设置有若干功能单元和若干门户单元，所述客户端50对应所述门户单元分别设置有显示界面；在所述系统中实现以下步骤：
当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息；
通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知；
在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，获得菜单显示文件；
将所述菜单显示文件发送到对应的显示界面，更新所述显示界面的菜单。
如图6所示，所述系统40可以划分为多个功能模块，具体包括菜单代理模块41、消息中间件集群42、菜单变化管理模块43、菜单定义模块44、菜单存储模块45、菜单合并模块46和菜单显示模块51。
菜单代理模块41，设置在服务器40中的每一功能单元中，用于采集各个独立部署功能单元上功能变化时生成的菜单变化消息。
以代理形式在各个独立部署功能单元上，在该单元部署时，菜单代理模块41负责收集本单元的菜单定义文件，发送注册消息，功能卸载时，获取本单元的所有注册过的菜单标识，发送菜单卸载消息。
消息中间件集群42，用于通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知。
以集群方式部署的消息中间件，负责接收菜单相关的消息，并通知监听菜单变化的消息消费者。本实施例中使用kafka集群，kafka是一种高吞吐量的分布式发布订阅消息系统，对接收到的消息会持久化到本地硬盘。集群部署方式，即使某个kafka实例不正常，也不会影响系统中的菜单注册、卸载；消息在硬盘持久化，即使kafka整个重启，消息也不会丢失。保证了动态菜单管理系统的健壮性。使用kafka来做消息转发，使得整个系统中不再需要有一个专门用户菜单处理的中心节点，没有写入存储的菜单信息都保存在kafka上，一旦有可以进行菜单处理的单元启动或正常运行，就可以进行菜单消息处理、入库、合并等。
菜单变化管理模块43，设置在各个门户单元中，用于监听所述菜单变化消息，并对所述菜单变化信息进行解析处理。
菜单变化管理模块43部署在门户单元上，根据系统的需求，会有1-n个门户单元，这些门户单元上的菜单变化管理模块43负责监听消息中间件上的菜单消息，对菜单进行持久化处理，若监听到菜单注册消息，则将解析菜单注册消息中的菜单信息，新增或修改菜单存储；若监听到菜单卸载消息，则解析菜单卸载消息中的菜单标识信息，删除菜单存储中的对应菜单。
菜单定义模块44，设置在每一功能单元中，用于根据统一菜单模型分别定义每一功能单元的菜单，并生成对应的菜单定义文件。
按照统一菜单模型定义开发菜单实例文件，一个菜单实例文件中可以有1-n个菜单，同一个独立部署功能单元(可以是微服务、插件等)可以多有个菜单文件。这些文件为json格式，放置在微服务的固定文件夹下。
菜单存储模块45，用于利用分布式数据库或分布式缓存对各个功能单元对应的菜单信息进行持久化处理，生成菜单集合。
菜单合并模块46，检测所述门户单元是否提供部分功能集合，当只需要提供部分功能时，读取所述门户单元所需要展示的菜单标识信息与所述菜单集合，所述菜单标识信息和所述菜单集合取交集后得到菜单合并集合；将所述菜单合并集合组织形成菜单树结构，按照显示格式对菜单树节点进行转换，生成菜单显示文件。
菜单合并模块46部署在门户单元上，负责菜单存储中读取菜单，进行合并。合并前，会判断本门户单元是否只需要提供部分功能的集合，若是，会取得本门户单元需要的菜单和系统中已经存在的菜单的交集作为菜单合并集合。合并时，根据配置的parent ID，来组织菜单树结构，把parent ID相同的菜单放到一层，并且根据order配置进行同一层的菜单排序，同层的菜单如果group相同，则认为是一组，同一组的菜单放到一起。树结构生成之后，再按照显示的格式，对菜单树节点进行转换，转换为界面显示需要的格式。本实施例中转换为浏览器可以直接解析的html片段。
菜单显示模块51，设置在客户端50上，用于更新显示各个门户单元通过的功能菜单。客户端50可以是浏览器等应用程序，集成安装在移动终端产品上。
具体的，系统由1-n个可以独立部署功能单元构成(独立部署功能单元可以是微服务或者插件)，每个独立部署的功能单元上有菜单定义模块和菜单代理模块，负责本单元的菜单定义和注册；消息中间件负责系统中的消息传递，以集群方式部署，本身具备健壮性；系统中部署有1-n个门户单元(是一种用于展示系统入口的独立部署单元)，这些门户单元上包含菜单的变动处理模块和菜单合并模块，负责菜单的集成；菜单存储模块负责菜单的持久化(存储或者删除)；菜单显示模块负责菜单的展示。
上述动态菜单处理系统是一种去中心化的架构，系统中不需要一个集中的菜单处理模块来集中做菜单变化监听、菜单变化处理、菜单合并处理。在各个模块的启动顺序上，也没有限制，菜单变化处理模块、菜单合并模块即使在菜单注册之后再启动，也能在启动之后获取到已经注册的菜单。
实施例4
本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，一个或者多个程序可被一个或者多个处理器执行，以实现如上述菜单动态管理方法的步骤。
如图7所示，该一个或者多个程序具体执行具体如下：
步骤S601，判断当前是功能部署还是卸载；
步骤S602，卸载则获取本微服务相关的菜单标识，发送菜单卸载消息到消息中间件(本实施例中使用消息中间件kafka)；或者步骤S603，部署则查找本微服务指定文件夹下的菜单文件，进行文件解析，将解析后的信息发送菜单注册消息到消息中间件；
步骤S604，菜单代理模块监听消息中间件的菜单变化消息，读取消息；
步骤S605，判断是菜单注册消息还是菜单卸载消息；
步骤S606，若是菜单卸载消息，则取出需要删除的菜单标识，在存储中将对应菜单删除；(本实施例中使用的存储装置为PostGre分布式缓存)；步骤S607，若是菜单注册消息，则取出菜单内容，进行校验，把校验后的菜单信息存储起来；
步骤S608，读取存储中的所有菜单；
步骤S609，判断是否需要进行菜单定制(在门户单元只需要展示部分功能集合场景下，需要展示的菜单不是全集)；
步骤S610，若不需要进行菜单定制，则获取本门户单元中需要展示的菜单标识与所有菜单取交集，作为待合并的菜单合并集合；
步骤S611，把菜单合并集合进行去重，按照层次关系定义，组织成有序的菜单树状结构，再根据展示的需要将其转换为可以直接显示的菜单结构，持久化为菜单显示文件；(本实施例中将其转换为可以直接在浏览器显示的html片段)
步骤S612，将转换后的菜单显示文件进行显示。(本实施例中是浏览器发起对合并后的菜单文件的访问，将菜单文件读取到浏览器后，加载到页面中)。
根据以上技术方案，可知本发明实施例提供的菜单动态管理方法、系统和计算机可读存储介质，通过消息中间件集群对菜单变化消息的转发和暂存，不再需要有一个专门用于菜单处理的中心节点，没有写入存储的菜单信息都保存在消息中间件上，一旦有可以进行菜单处理的单元启动或正常运行，就可以进行菜单消息处理、存储、合并等；消息中间件的集群部署模式，即使某个消息中间件实例不正常，也不会影响系统中的菜单注册、卸载。系统采用了去中心化架构，在各个模块的启动顺序上没有依赖关系，菜单变化处理模块、 菜单合并模块即使在菜单注册之后再启动，也能在启动之后获取到已经注册的菜单。
另外，通过创建菜单统一模型，使得菜单定义更加规范、一致，保证菜单注册及后续合并逻辑的正确性。菜单合并时，根据所在门户单元定义的功能子集，对系统中现有的菜单集合进行定制，使菜单处理更加灵活。功能的所有变化，都可以灵活的进行菜单的修改，使得菜单与功能一致。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形 式，这些均属于本发明的保护之内。

Claims (9)

  1. 一种菜单动态管理方法，其特征在于，所述方法包括：
    当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息；
    通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知；
    在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，更新界面显示的菜单。
  2. 根据权利要求1所述的菜单动态管理方法，其特征在于，所述采集功能变化生成的菜单变化消息之前，所述方法还包括：
    创建一统一菜单模型，根据所述统一菜单模型分别定义每一功能单元的菜单，并生成对应的菜单定义文件。
  3. 根据权利要求1所述的菜单动态管理方法，其特征在于，所述菜单变化消息包括菜单注册消息和菜单卸载消息。
  4. 根据权利要求3所述的菜单动态管理方法，其特征在于，对所述菜单变化信息进行解析处理包括：
    当监听到所述菜单注册消息时，解析所述菜单注册消息中的菜单信息，新增或修改菜单集合；
    当监听到所述菜单卸载消息时，解析所述菜单卸载消息中的菜单标识信息，删除菜单集合中的对应菜单。
  5. 根据权利要求1所述的菜单动态管理方法，其特征在于，所述采集功能变化生成的菜单变化消息之前，所述方法还包括：
    利用分布式数据库或分布式缓存对每一功能单元对应的菜单信息进行保存，生成菜单集合。
  6. 根据权利要求5所述的菜单动态管理方法，其特征在于，所述在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，更新界面显示的菜单之后，所述方法还包括：
    当所述门户单元提供部分功能集合时，获取所述门户单元所展示菜单对应的菜单标识信息与所述菜单集合，所述菜单标识信息和所述菜单集合取交集后得到菜单合并集合；
    将所述菜单合并集合组织形成菜单树结构，按照显示格式对菜单树节点进行转换，生成菜单显示文件。
  7. 根据权利要求6所述的菜单动态管理方法，其特征在于，所述生成菜单显示文件之后，所述方法还包括：将所述菜单显示文件发送到对应的显示界面，更新显示界面的菜单。
  8. 一种服务器，其特征在于，所述服务器包括处理器、存储器及数据总线；
    所述数据总线用于实现处理器和存储器之间的连接通信；
    所述处理器用于执行存储器中存储的内存模型计算程序，以实现以下步骤：
    当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息；
    通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知；
    在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，获得菜单显示文件。
  9. 一种菜单动态管理系统，其特征在于，所述系统包括至少一服务器以及若干客户端，所述服务器中设置有若干功能单元和若干门户单元，所述客户端对应所述门户单元分别设置有显示界面；在所述系统中实现以下步骤：
    当独立部署功能单元上的功能变化时，采集功能变化生成的菜单变化消息；
    通过集群方式部署的消息中间文件接收所述菜单变化消息，并对所述菜单变化消息进行广播通知；
    在门户单元监听所述菜单变化消息，并对所述菜单变化信息进行解析处理，获得菜单显示文件；
    将所述菜单显示文件发送到对应的显示界面，更新所述显示界面的菜单。
PCT/CN2019/092478 2018-06-25 2019-06-24 菜单动态管理方法、服务器和系统 WO2020001391A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19825890.7A EP3812893A4 (en) 2018-06-25 2019-06-24 DYNAMIC MANAGEMENT PROCESS FOR MENU, SERVER AND SYSTEM
US17/055,123 US11169863B2 (en) 2018-06-25 2019-06-24 Dynamic management method for menu, server and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810665814.5A CN110633157A (zh) 2018-06-25 2018-06-25 菜单动态管理方法、服务器、系统和计算机可读存储介质
CN201810665814.5 2018-06-25

Publications (1)

Publication Number Publication Date
WO2020001391A1 true WO2020001391A1 (zh) 2020-01-02

Family

ID=68968179

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/092478 WO2020001391A1 (zh) 2018-06-25 2019-06-24 菜单动态管理方法、服务器和系统

Country Status (4)

Country Link
US (1) US11169863B2 (zh)
EP (1) EP3812893A4 (zh)
CN (1) CN110633157A (zh)
WO (1) WO2020001391A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11526825B2 (en) * 2020-07-27 2022-12-13 Cygnvs Inc. Cloud-based multi-tenancy computing systems and methods for providing response control and analytics
CN113778442A (zh) * 2021-09-10 2021-12-10 未鲲(上海)科技服务有限公司 一种系统菜单生成方法、装置、设备及存储介质
US12041062B2 (en) 2021-09-15 2024-07-16 Cygnvs Inc. Systems for securely tracking incident data and automatically generating data incident reports using collaboration rooms with dynamic tenancy
US11477208B1 (en) 2021-09-15 2022-10-18 Cygnvs Inc. Systems and methods for providing collaboration rooms with dynamic tenancy and role-based security
CN115390719B (zh) * 2022-09-07 2023-09-19 中移互联网有限公司 聊天机器人消息页面菜单管理方法及电子设备、存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101330674A (zh) * 2007-06-21 2008-12-24 上海美通无线网络信息有限公司 一种动态更新手机软件菜单的方法
CN101374273A (zh) * 2007-08-24 2009-02-25 深圳华为通信技术有限公司 基于多媒体消息业务实现服务的方法、系统、终端和服务器
CN101661387A (zh) * 2008-08-29 2010-03-03 北京数码大方科技有限公司 用于管理系统的菜单动态加载方法
CN102436380A (zh) * 2011-11-15 2012-05-02 福源立信（北京）科技有限公司 一种stk菜单处理系统及其对菜单的处理方法
CN104394283A (zh) * 2014-08-27 2015-03-04 贵阳朗玛信息技术股份有限公司 Ivr菜单的动态调整方法及系统

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8364145B2 (en) * 2008-01-09 2013-01-29 Mediatek Inc. Methods and devices for dynamic menu update
JP5169237B2 (ja) * 2008-01-16 2013-03-27 富士通株式会社 通信伝送装置および通信伝送方法
US10492102B2 (en) * 2009-01-28 2019-11-26 Headwater Research Llc Intermediate networking devices
US9081580B2 (en) * 2011-03-31 2015-07-14 Oracle International Corporation Real-time menu architecture
US9563336B2 (en) * 2012-04-26 2017-02-07 Liveperson, Inc. Dynamic user interface customization
US20140228014A1 (en) * 2013-02-12 2014-08-14 Mistral Mfs Oy Method, System and Computer Program for Remotely Configurable Mobile Application
US20140282248A1 (en) * 2013-03-12 2014-09-18 Microsoft Corporation Enhanced views with dynamic menus
US20150120463A1 (en) * 2013-10-29 2015-04-30 AUTONETTV MEDIA, Inc. System and method for advertisement distribution
CN105242937A (zh) * 2014-06-27 2016-01-13 中兴通讯股份有限公司 一种动态更新应用界面的方法、终端及系统
US10027728B2 (en) * 2015-03-06 2018-07-17 Ebay Inc. Systems and methods of streaming data
CN107643927A (zh) * 2016-07-20 2018-01-30 中兴通讯股份有限公司 一种统一门户方法、装置及系统
CN107426004A (zh) * 2017-05-03 2017-12-01 深圳市众泰兄弟科技发展有限公司 一种基于大数据的网络安全可视化处理方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101330674A (zh) * 2007-06-21 2008-12-24 上海美通无线网络信息有限公司 一种动态更新手机软件菜单的方法
CN101374273A (zh) * 2007-08-24 2009-02-25 深圳华为通信技术有限公司 基于多媒体消息业务实现服务的方法、系统、终端和服务器
CN101661387A (zh) * 2008-08-29 2010-03-03 北京数码大方科技有限公司 用于管理系统的菜单动态加载方法
CN102436380A (zh) * 2011-11-15 2012-05-02 福源立信（北京）科技有限公司 一种stk菜单处理系统及其对菜单的处理方法
CN104394283A (zh) * 2014-08-27 2015-03-04 贵阳朗玛信息技术股份有限公司 Ivr菜单的动态调整方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3812893A4 *

Also Published As

Publication number Publication date
EP3812893A1 (en) 2021-04-28
CN110633157A (zh) 2019-12-31
US20210216381A1 (en) 2021-07-15
EP3812893A4 (en) 2022-03-16
US11169863B2 (en) 2021-11-09

Similar Documents

Publication Publication Date Title
WO2020001391A1 (zh) 菜单动态管理方法、服务器和系统
US11561784B2 (en) Versioning of pipeline templates for continuous delivery of services on datacenters configured in cloud platforms
CN101789888B (zh) 一种软件安装的检测方法和装置
US8032880B2 (en) Multi-branch management for updating software
CN110636093B (zh) 微服务注册和发现方法、设备、存储介质以及微服务系统
CN108052340B (zh) 一种应用升级方法、装置
CN111078504A (zh) 一种分布式调用链跟踪方法、装置、计算机设备及存储介质
US9105001B2 (en) Analytic solution integration
CN110019312B (zh) 读写数据分离调度方法、装置、设备及介质
CN108427550B (zh) 一种Web服务生成方法、装置及设备
US11055180B2 (en) Backup management of software environments in a distributed network environment
US20130225148A1 (en) Terminal with module protection and module managing method
US20150142813A1 (en) Language tag management on international data storage
KR20160122254A (ko) 소프트웨어 애플리케이션의 세트의 구축 방법
US11392366B1 (en) Optimized compilation of pipelines for continuous delivery of services on datacenters configured in cloud platforms
CN110543512B (zh) 一种信息同步方法，装置及系统
CN103309985A (zh) 针对服务注册中心的业务服务注册与发布方法及其系统
EP2438709B1 (en) Network element integration
US20230259358A1 (en) Documentation enforcement during compilation
CN109992279A (zh) 配置数据更新方法、装置、计算设备及存储介质
US9235437B2 (en) Method and integration component for integrating OSGi environments into a Service-oriented Architecture
CN105787359B (zh) 进程守护方法和装置
CN112817603A (zh) 应用程序处理方法、装置、电子设备、系统和存储介质
KR101546581B1 (ko) 어플리케이션 다운로드 방법 및 그 방법을 수행하는 사용자 단말
KR20170051718A (ko) 사물 자원 정보 공유 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19825890

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019825890

Country of ref document: EP

Effective date: 20210125