A method and system for constructing an enterprise address book architecture

Abstract

The present invention relates to a method for constructing an enterprise address book architecture, the construction method comprising the steps of: mounting different subsidiaries under the departments of an enterprise according to email domain names; mounting enterprises with different email domain names under the departments of the same enterprise; and setting fields for pointing to actual departments and actual enterprises in a department storage table. Compared with the prior art, the present invention reconstructs and displays the organizational structure of the physical enterprises and physical departments corresponding to different email domain names as needed, with flexible configuration, convenient addition, deletion and modification, and no need to be restricted by the restrictions of email domain names.

Description

Technical Field

[0001] The present invention relates to the technical field of office software, and in particular to a method and system for constructing an enterprise address book architecture. Background Art

[0002] Due to the huge address book system of large enterprises and the different email domain names of each branch, the built-in address book of the email system is distinguished by email domain name, resulting in Branch A and Branch B being two unrelated companies due to different domain names, and it is impossible to synthesize a unified corporate address book suitable for the company. When searching, associating and searching for departments and users, the time loss caused by enterprise switching is low efficiency.

[0003] Therefore, it is necessary to construct an address book system with flexible configuration, not subject to the restrictions of email domain names, and with a complete organizational structure tree. Summary of the invention

[0004] The purpose of the present invention is to provide a method and system for constructing an enterprise address book architecture in order to overcome the defects of the above-mentioned prior art.

[0005] The purpose of the present invention can be achieved by the following technical solutions:

[0006] As a first aspect of the present invention, a method for constructing an enterprise address book architecture is provided, the construction method comprising the following steps:

[0007] Mount different subsidiaries under the company's departments based on their email domain names;

[0008] Mount enterprises with different email domain names under the same enterprise department;

[0009] Set up fields in the department storage table to point to the actual department and the actual enterprise.

[0010] Furthermore, the method of registering different subsidiaries in departments of different enterprises according to email domain names specifically includes:

[0011] Multiple subsidiaries using the same email domain name are registered under the same enterprise department;

[0012] A subsidiary that uses an independent email domain name will be mounted separately under a department of an enterprise.

[0013] Furthermore, the department under the subsidiary that independently uses an email domain name is mounted to a subsidiary of another domain name as its department.

[0014] Furthermore, after the department is mounted, the sub-departments of the department will be displayed under the parent department.

[0015] Furthermore, the personnel information within each of the departments is displayed synchronously.

[0016] Furthermore, the fields set when storing the department include:

[0017] The virtual department field indicates the department ID of the real department pointed to by the virtual department. If it is a real department, it is 0.

[0018] The virtual enterprise field indicates the enterprise ID of the real department pointed to by the virtual department. If it is a real department itself, the value is 0.

[0019] Furthermore, when the department has no department mounted, the virtual department field is 0, indicating that no department is mounted;

[0020] The virtual enterprise field refers to the enterprise ID corresponding to the mounted department when the department is mounted.

[0021] Furthermore, each of the departments corresponds to two department IDs: the actual department ID of the department and the department ID mounted under the department.

[0022] As a second aspect of the present invention, there is provided an enterprise address book system constructed by applying any of the above-mentioned methods for constructing an enterprise address book architecture, the system comprising:

[0023] Front-end display module: Based on the department mounting results, the unified organizational structure of multiple email domains and multiple enterprises is displayed; after the parent department is mounted, its sub-departments will be automatically displayed under the parent department, and the personnel information within the department will be displayed synchronously;

[0024] Address book service module: used to point the virtual department to the real department, and add two fields in the department storage table: the virtual department field indicates the real department ID pointed to by the virtual department. If it is a real department, it is 0; the virtual enterprise field indicates the real department enterprise ID pointed to by the virtual department. If it is a real department, it is 0.

[0025] Furthermore, the system also includes: a department and user information query module: used to query the sub-departments and user lists under the enterprise or department:

[0026] The interface for querying department information returns three fields: whether this department points to other departments, the enterprise ID of the actual department to which this department points, and the department ID of the actual department to which this department points;

[0027] When the above three returned results are not 0, perform cross-domain query for user information based on the returned results;

[0028] When the returned result is 0, it means that the department is a physical department, and the actual department field and the actual enterprise field are returned, and user information is queried within the domain name.

[0029] Compared with the prior art, the present invention has the following beneficial effects:

[0030] 1) The present invention constructs a flexible organizational structure system. By building virtual departments, the physical enterprises and physical departments corresponding to different email domain names are rebuilt and displayed as needed, and the existing organizational structure of multiple enterprises is processed from the enterprise to the department into a new and more readable set of organizational structure trees. The configuration is flexible, and addition, deletion and modification are convenient, without being restricted by the restrictions of email domain names.

[0031] 2) The structure of the present invention combines multiple recipient domains into the same virtual subdomain, which reduces the waiting time caused by enterprise switching during search, association and search, and greatly improves the user's applicability. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 It is a flowchart of the method for constructing the enterprise address book architecture of the present invention. DETAILED DESCRIPTION

[0033] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. This embodiment is implemented based on the technical solution of the present invention, and provides a detailed implementation method and specific operation process, but the protection scope of the present invention is not limited to the following embodiments.

[0034] Example 1

[0035] The present invention is a highly flexible solution for displaying a large number of corporate address books. If multiple subsidiaries use the same domain name, these subsidiaries with the same domain name are considered as departments of the same enterprise. If a subsidiary uses a domain name independently, the subsidiary corresponds to one enterprise, and the department under the subsidiary is mounted to a company with another domain name as its department; the main design steps are as follows:

[0036] S1 mounts different subsidiaries under the company's departments based on email domain names;

[0037] Multiple subsidiaries using the same email domain name will be mounted under the department of the same enterprise. Subsidiaries that use an independent email domain name will be mounted separately under the department of an enterprise, and the departments under its subsidiaries will be mounted under subsidiaries of other domain names as their departments.

[0038] S2 mounts enterprises with different email domain names under the departments of the same enterprise;

[0039] After a department is mounted, its sub-departments will be automatically displayed under the parent department, and the personnel information within the department will be displayed synchronously.

[0040] S3 sets fields in the department storage table to point to the actual department and the actual enterprise.

[0041] When storing a department, the fields set include: a virtual department field, which indicates the department ID of the real department pointed to by the virtual department. If it is a real department, it is 0; a virtual enterprise field, which indicates the enterprise ID of the real department pointed to by the virtual department. If it is a real department, it is 0. Each department corresponds to two department IDs: the actual department ID of the department and the department ID mounted under the department. When the department has no department mounted, the virtual department field is 0, indicating that no department is mounted; the virtual enterprise field refers to the enterprise ID corresponding to the mounted department when the department is mounted.

[0042] Example 2

[0043] As a second aspect of the present invention, there is provided an enterprise address book system constructed by applying the construction method of an enterprise address book architecture described in the above embodiment, the system comprising:

[0044] Front-end display module: It has the function of department mounting. By mounting the enterprises referred to by different domain names under the departments of a certain enterprise, it can realize the unified organizational structure display of multiple email domain names and multiple enterprises. You only need to mount the parent department, and its sub-departments will be automatically displayed under the parent department, and the personnel information within the department will be displayed synchronously.

[0045] Address book service module: Add two fields to the department storage table: virtual department field (indicates the real department ID pointed to by the virtual department. If it is a real department, it is 0) and virtual enterprise field (indicates the real department enterprise ID pointed to by the virtual department. If it is a real department, it is 0). In this way, each department will correspond to two department IDs: the actual department ID of the department and the department ID mounted under the department. When the department has no department mounted, the virtual department field is 0, indicating that no department is mounted. In addition, since the department is established under the enterprise, the virtual enterprise field refers to the enterprise ID corresponding to the mounted department when the department is mounted.

[0046] Module for querying department and user information: When you need to query the sub-departments and user lists under an enterprise or department, such as the recipient association function, the specific implementation steps are as follows: The interface for querying department information returns three more fields on the original basis: whether the department points to other departments, the enterprise ID of the actual department to which the department points (if it is an actual department, it is the enterprise ID), and the department ID of the actual department to which the department points (if it is an actual department, it is the id field of the department). When the above three returned results are not 0, perform cross-domain query of user information based on the returned results. When the returned result is 0, it means that the department is an actual department, and the actual department field and the actual enterprise field are returned, and the query can be performed within the domain. Merge multiple recipient domains into the same virtual subdomain to reduce the waiting time caused by enterprise switching during lookup, association, and search, greatly improving the user's applicability.

[0047] The preferred specific embodiments of the present invention are described in detail above. It should be understood that a person skilled in the art can make many modifications and changes based on the concept of the present invention without creative work. Therefore, any technical solution that can be obtained by a person skilled in the art through logical analysis, reasoning or limited experiments based on the concept of the present invention on the basis of the prior art should be within the scope of protection determined by the claims.

Claims

1. A method for constructing an enterprise address book architecture, characterized in that: The construction method comprises the following steps: Multiple subsidiaries using the same email domain name are registered under the same enterprise department; A subsidiary that uses an independent email domain name should be registered under a department of a company. Set up fields in the department storage table to point to the actual department and the actual enterprise; The fields set when storing the department include: The virtual department field indicates the department ID of the real department pointed to by the virtual department. If it is a real department, the value is 0. When the department has no department mounted, the virtual department field is 0, indicating that no department is mounted. The virtual enterprise field indicates the enterprise ID of the real department pointed to by the virtual department. If it is a real department, it is 0. When the department is mounted, the virtual enterprise field is the enterprise ID corresponding to the mounted department. Each department corresponds to two department IDs: the actual department ID of the department and the department ID mounted under the department; When querying the sub-departments and user lists under an enterprise or department, the specific implementation steps are as follows: The interface for querying department information returns three fields: whether this department points to other departments; the enterprise ID of the actual department to which this department points, if it is an actual department, it is the enterprise ID; the department ID of the actual department to which this department points, if it is an actual department, it is the id field of this department; When the above three returned results are not 0, perform cross-domain query on user information based on the returned results; When the returned result is 0, it means that the department is a physical department, and the actual department field and actual enterprise field are returned, and the query is performed within this domain.

2. The method for constructing an enterprise address book architecture according to claim 1, characterized in that: The department under the subsidiary that independently uses an email domain name is mounted to the subsidiary of another domain name as its department.

3. The method for constructing an enterprise address book architecture according to claim 1, characterized in that: After the department is mounted, the sub-departments of the department will be displayed under the parent department.

4. The method for constructing an enterprise address book architecture according to claim 3, characterized in that: The personnel information within each department is displayed synchronously.

5. An enterprise address book system constructed by using the method for constructing an enterprise address book architecture as described in any one of claims 1 to 4, characterized in that: The system comprises: Front-end display module: Based on the department mounting results, the unified organizational structure of multiple email domains and multiple enterprises is displayed; after the parent department is mounted, its sub-departments will be automatically displayed under the parent department, and the personnel information within the department will be displayed synchronously; Address book service module: used to point the virtual department to the real department, and add two fields in the department storage table: the virtual department field indicates the real department ID pointed to by the virtual department. If it is a real department, it is 0; the virtual enterprise field indicates the real department enterprise ID pointed to by the virtual department. If it is a real department, it is 0.

6. The enterprise address book system according to claim 5, characterized in that: The system also includes: a department and user information query module: used to query the sub-departments and user lists under an enterprise or department: The interface for querying department information returns three fields: whether this department points to other departments, the enterprise ID of the actual department to which this department points, and the department ID of the actual department to which this department points; When the above three returned results are not 0, perform cross-domain query for user information based on the returned results; When the returned result is 0, it means that the department is a physical department, and the actual department field and the actual enterprise field are returned, and user information is queried within the domain name.

Images