Business service system and method for executing business service

Abstract

A business service system and a method for executing business services. The business service system comprises a memory and a processor. In a data service layer, the processor constructs a plurality of business data models on the basis of the memory. The processor executes the plurality of business data models to invoke the memory so as to separately acquire standard data corresponding to different business fields. The processor shares in the data service layer the plurality of business data models, and constructs in a business service layer a plurality of business processing models on the basis of the plurality of business data models. The processor executes the plurality of business processing models to invoke the plurality of business data models to separately provide different business services for a plurality of corresponding tenants, so as to fuse data in different business fields by means of providing an innovative business middle platform architecture.

Description

Business service system and method for executing business service

[0001] This application claims priority to the Chinese patent application filed with the Patent Office of China on February 26, 2024, with application number 202410211212.8 and invention name “Business Service System and Method for Executing Business Services”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present invention relates to an application system, in particular to a business service system based on the architecture of an application business middle platform and a method for executing business services. Background Art

[0003] Figure 1 is a block diagram of a current business service system. Referring to Figure 1 , the business service system 10 represents the architecture of the business middle platform. The business service system 10 is capable of managing multiple business centers and providing various business services to the application front end 20. The business service system 10 is vertically divided into different business centers based on business areas, such as a sales business center 101, a procurement business center 102, a work order business center 103, and a process business center 104.

[0004] In other words, the business service system 10 organizes various business data and corresponding business services into different business centers, based on business domains. For example, business data for the sales domain (i.e., sales database tables) and corresponding business services (i.e., sales business services) are organized into the sales business center 101. Thus, the sales business services access data in the sales database tables within the sales domain.

[0005] However, when the application frontend 20 supports multiple application systems from multiple independent software vendors (ISVs), the current business service system 10 is unable to build or optimize multiple specialized and detailed business centers to accommodate the diverse application scenarios required by different ISVs. Furthermore, as design requirements increase, the demand information for each business center in the business service system 10 also increases. This requires more development resources for the business service system 10, leading to increased costs.

[0006] On the other hand, because multiple ISVs operate in different industries and / or application scenarios, their application systems often use different data standards and definitions. Consequently, the current business service system 10 cannot guarantee consistency in data standards and definitions across different business domains, resulting in data incompatibility and, consequently, discrepancies in business services developed by the same ISV in different application scenarios.

[0007] Summary of the Invention

[0008] The present invention is directed to a business service system, applicable to a business middle platform, capable of integrating data in different business fields, and thus supporting the business services required by multiple ISVs.

[0009] According to an embodiment of the present invention, a business service system includes a memory and a processor. The processor is coupled to the memory. In a data service layer, the processor constructs multiple business data models based on the memory. The processor executes the multiple business data models to call the memory to retrieve standard data corresponding to different business domains. The processor shares the multiple business data models in the data service layer and constructs multiple business processing models based on the multiple business data models in the business service layer. The processor executes the multiple business processing models to call the multiple business data models to provide different business services to corresponding multiple tenants.

[0010] According to an embodiment of the present invention, a method for executing a business service includes the following steps. In a data service layer, a processor constructs multiple business data models based on memory. The processor executes the multiple business data models to call memory to retrieve standard data corresponding to different business domains. The processor shares the multiple business data models in the data service layer, and constructs multiple business processing models in the business service layer based on the multiple business data models. The processor executes the multiple business processing models to call the multiple business data models to provide different business services to corresponding multiple tenants.

[0011] Based on the above, the business service system and the method for executing business services of the present invention can avoid coupling service applications and corresponding business data in the business center of the same business domain by sharing multiple business data models in the data service layer to build multiple business processing models, and thus develop based on the same multiple business data models. In this way, the business service system can integrate business data in different business domains to reduce development costs, and can also ensure that various business processing models in different business domains apply the same data standards and definitions. Therefore, the business service system can provide various business services to different tenants (for example, different ISVs).

[0012] In order to make the above features and advantages of the present invention more clearly understood, embodiments are given below with reference to the accompanying drawings for detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is a block diagram of the current business service system;

[0014] FIG2 is a block diagram of a business service system according to an embodiment of the present invention;

[0015] FIG3 is a flowchart of a method for executing a business service according to an embodiment of the present invention;

[0016] FIG4 is a schematic diagram of the operation of a business service system according to an embodiment of the present invention;

[0017] FIG5 is a schematic diagram of the layered architecture of the data service layer of the embodiment of FIG4 of the present invention;

[0018] 6A to 6B are schematic diagrams illustrating the operation of the business service system according to the embodiment of FIG. 4 of the present invention;

[0019] 7A to 7H are schematic diagrams of the operation of the business service system according to the embodiment of FIG. 4 of the present invention;

[0020] FIG8 is a schematic diagram of the operation of a business data model according to an embodiment of the present invention;

[0021] FIG9A is a schematic diagram of an application of the business data model of the embodiment of FIG8 of the present invention;

[0022] FIG. 9B is a schematic diagram illustrating an application of the entity data model according to the embodiment of FIG. 8 of the present invention.

[0023] Description of Reference Numerals

[0024] 10: Business service system;

[0025] 20: Application foreground;

[0026] 101-104: Business Center;

[0027] 300, 500, 900: business service system;

[0028] 310, 510: processor;

[0029] 320, 520: memory;

[0030] 330, 530: data service layer;

[0031] 331-33M, 531-533, 931-933: business data model;

[0032] 335: Linked Data Model;

[0033] 340: business service layer;

[0034] 341~34N: Business processing model;

[0035] 351-359: Service Center;

[0036] 400: Application foreground;

[0037] 401-40N: Independent Software Developer (ISV);

[0038] 411-415: Application system;

[0039] 420, 430: end user;

[0040] 521: Industry terminology database;

[0041] 522: field library;

[0042] 522a: Metadata Management Model;

[0043] 522b: Governance Instrument Model;

[0044] 523: Mapping vocabulary;

[0045] 525: cache;

[0046] 532: Data management layer;

[0047] 533: data storage layer;

[0048] 534: Data access layer;

[0049] 535: Business model layer;

[0050] 541: Permission check model;

[0051] 542: Model parsing model;

[0052] 543: Data access model;

[0053] 544: Service Governance Model;

[0054] 551, 951-953: Entity Data Model;

[0055] 620a: System Management Center;

[0056] 624: Model library;

[0057] API_F1~API_F2, API_F4~API_F5, API_F31: Application Programming Interface (API);

[0058] API_F3: data service;

[0059] D1-D5: database;

[0060] Din: business input parameters;

[0061] DS1: System Data Standard;

[0062] DS2: Business data standard;

[0063] DT: Characterization tag;

[0064] F71~F72: box;

[0065] F101~F102: fields;

[0066] S310~S340, S610~S690: steps. DETAILED DESCRIPTION

[0067] Reference will now be made in detail to exemplary embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Whenever possible, the same reference numerals are used in the drawings and the description to refer to the same or like parts.

[0068] Figure 2 is a block diagram of a business service system according to an embodiment of the present invention. Referring to Figure 2 , the business service system 300 employs the architecture of a business middle platform. The business service system 300 allows multiple tenants (e.g., ISVs) to design their own applications and provide corresponding business services to the application frontend 400.

[0069] In this embodiment, in the application frontend 400, multiple ISVs 401-40N can build corresponding multiple application systems 411-415 in their respective private clouds, where N is a positive integer. For example, ISV 401 may be a developer of applications in the equipment manufacturing industry. ISV 401 develops a Digital Cockpit Platform (DCP) device navigation application system 411 and a center console application system 412. ISV 402 may be a developer of applications in the parts industry. ISV 402 develops a production management application system 413 and an inspection and analysis application system 414.

[0070] Continuing with the above description, multiple application systems 411-415 invoke business service system 300 via corresponding application programming interfaces (APIs) to execute multiple applications (e.g., multiple business process models 341-34N), enabling business service system 300 to provide corresponding business services. Application systems 411-415 may be, for example, Software as a Service (SaaS) servers.

[0071] In this embodiment, the business service system 300 may include a processor 310 and a memory 320. The processor 310 is coupled to the memory 320 and the application front end 400. The business service system 300 can be implemented as a server set up in a private cloud and / or a public cloud. In this embodiment, the memory 320 can store computing software and the like for implementing the algorithms, programs and data related to the construction, calling, and various calculation functions of the present invention. The memory 320 can be, for example, dynamic random access memory (DRAM), flash memory, non-volatile random access memory (NVRAM) or a combination of these memories.

[0072] In this embodiment, the processor 310 accesses the memory 320 and can execute data in the memory 320. The processor 310 can also access multiple application systems 411-415 in the application foreground 400. In this embodiment, the processor 310 can be, for example, a server, a signal converter, a field programmable gate array (FPGA), a central processing unit (CPU), or other programmable general-purpose or special-purpose microprocessor, digital signal processor (DSP), programmable controller, application specific integrated circuit (ASIC), programmable logic device (PLD), or other similar devices or combinations of these devices, which can load and execute computer program-related firmware or software to implement functions such as building, calling, and various calculations.

[0073] Figure 3 is a flowchart of a method for executing a business service according to one embodiment of the present invention. Referring to Figures 2 and 3 , business service system 300 can access memory 320 via processor 310 and execute steps S310 through S340 via processor 310. The order of steps S310 through S340 is for illustrative purposes only and is not intended to be limiting. The number of models in business service system 300 is for illustrative purposes only.

[0074] In step S310, in the data service layer 330, the processor 310 constructs a plurality of business data models 331-33M based on the memory 320, where M is a positive integer. M may be the same as or different from N. The data service layer 330 may be, for example, a persistence layer. The plurality of business data models 331-33M may be implemented, for example, using firmware or software.

[0075] In step S320, processor 310 executes the multiple business data models 331-33M in step S310, causing the multiple business data models 331-33M to access memory 320 to retrieve standard data corresponding to different business domains. Standard data can be represented, for example, by multiple fields. Standard data can include standardized data content and corresponding attribute constraints applicable to various business domains and corresponding industries.

[0076] That is, the multiple business data models 331 - 33M are constructed as multiple independent applications according to different business domains. The processor 310 obtains standard data applied in different business domains through the multiple business data models 331 - 33M.

[0077] For example, business data model 331 accesses memory 320 to retrieve standard data for the procurement domain. This standard data may include standard data such as the purchase contract table, purchase order header table, and purchase order detail table. For another example, business data model 332 accesses memory 320 to retrieve standard data for the sales application domain. Business data model 333 accesses memory 320 to retrieve standard data for the manufacturing domain. Business data model 3354 accesses memory 320 to retrieve standard data for other domains.

[0078] In this embodiment, the business data model 33M can be used, for example, in the inventory domain and used to retrieve standard data such as a product number table, inventory quantity table, and delivery order detail table. The business data model 33M can also be used, for example, in the project domain and used to retrieve standard data such as a project type table, a project task template parameter table, and a project task detail table. The business data model 33M can also be used, for example, in the bill of materials (BOM) domain and used to retrieve standard data such as a BOM information table, a BOM detail information table, and a BOM component information table.

[0079] In step S330, processor 310 shares multiple business data models 331-33M in data service layer 330 and constructs multiple business process models 341-34N based on the multiple business data models 331-33M in business service layer 340. Each business process model 341-34N may include one or more service centers. Business service layer 340 may be, for example, a business layer. Multiple business data models 341-34N may be implemented, for example, in firmware or software.

[0080] That is, different ISVs 401-40N are not constrained by business domains. ISVs 401-40N can share the data service layer 330 to access multiple business data models 331-33M. In this way, ISVs 401-40N can each build multiple business process models 341-34N based on their respective needs. The aforementioned needs may include business service needs that span multiple business domains. In addition, since each constructed business process model 341-34N can be encapsulated as an executable program, different ISVs 401-40N can also share these business process models 341-34N in the business service layer 340. In this way, ISVs 401-40N can use the multiple business process models 341-34N built by each other to meet various business services.

[0081] Specifically, ISV 401 invokes business service system 300 to cause processor 310 to construct business process model 341 based on multiple business data models 331-333. Business process model 341 may include multiple service centers 351-354 across business domains. Each service center 351-354 may include one or more corresponding APIs.

[0082] For example, based on procurement needs, the processor 310 constructs a procurement business service center 351 and an arrival business service center 352 according to the business data model 331. The procurement business service center 351 may include a procurement contract change API, a purchase order creation API, and a procurement price acquisition API. Therefore, the ISV 401 can operate the business service system 300 to provide procurement business services to its own multiple application systems 411-412 according to the procurement business service center 351. For another example, the ISV 401 calls the business service system 300 based on manufacturing needs, so that the processor 310 constructs a work order business service center 353 according to the business data model 333. Based on sales application needs, the processor 310 constructs other business service centers 354 according to the business data model 332.

[0083] Furthermore, ISV 402 invokes business service system 300 to cause processor 310 to construct business process model 342 based on multiple business data models 333-334. Business process model 342 may include multiple service centers 355-358 across business domains. These service centers 355-358 are described with reference to service center 35 and by analogy.

[0084] It should be noted that the different work order business service centers 353 and 355 are service centers designed by different ISVs 401 and 402 according to their respective needs. Therefore, these work order business service centers 353 and 355 can be applied in different scenarios. In addition, because the processor 310 designs these work order business service centers 353 and 355 based on the same business data model 333, different business processing models 341 and 342 can also communicate (for example, directly call) these work order business service centers 353 and 355 without any differences. In other words, different ISVs 401-40N can share each other's business processing models 341-34N and their corresponding multiple service centers.

[0085] For example, ISV 402, because multiple application systems 413-414 also have procurement requirements, can operate business service system 300 to access procurement business service center 351 designed by ISV 401. Thus, based on procurement business service center 351 in business process model 341, business service system 300 can further provide procurement business services to other tenants (i.e., ISV 402), thereby implementing procurement services for multiple application systems 413-414.

[0086] In step S340, the processor 310 executes the multiple business process models 341-34N, so that the multiple business process models 341-34N call the multiple business data models 331-33M to provide different business services to the corresponding multiple tenants (i.e., multiple ISVs 401-40N) in the application frontend 400. In other words, the processor 310 calls the corresponding multiple business data models 331-33M through the multiple service centers 351-359 in the multiple business process models 341-34N to implement various business services.

[0087] It should be noted that the multiple business process models 341-34N access corresponding data by invoking data services, rather than directly accessing database tables in memory 320. As such, these business process models 341-34N are not restricted by the management permissions of different ISVs 401-40N. Consequently, processor 310 can directly execute these business process models 341-34N, thereby increasing the flexibility of business service system 300.

[0088] It is worth mentioning that the business service system 300 horizontally divides the business services used to provide logic (i.e., multiple business processing models 341-34N) and the business data used to provide data (i.e., multiple business data models 331-33M) into the business service layer 340 and the data service layer 330. Therefore, the business service system 300 no longer couples business services and business data in the same business domain into the same service center, thereby providing an innovative business middle-end architecture.

[0089] Continuing with the above description, the business service system 300 shares multiple business data models 331~33M in the data service layer 330, and the multiple business processing models 341~34N constructed can be developed based on the same business data. In addition, these business processing models 341~34N are differentiated according to multiple ISVs 401~40N, and are no longer limited to business fields. In other words, the business service system 300 can integrate business data in different business fields and avoid building duplicate business data, thereby reducing the development cost of each ISV 401~40N. The business service system 300 can ensure that multiple business processing models 341~34N in different business fields apply the same data standards and definitions (i.e., standard data) to provide corresponding business services to multiple tenants.

[0090] Referring again to Figure 2 , the data service layer 330 provides basic CRUD (Create, Delete, Read, and Update) data services. Specifically, the processor 310 performs operations such as adding (i.e., creating), deleting (i.e., deleting), querying (i.e., reading), and modifying (i.e., updating) business data in the data service layer 330.

[0091] In this embodiment, memory 320 also stores multiple entity data models (EDMs) corresponding to different business domains (e.g., EDM 551 shown in FIG. 4 ). These EDMs correspond to multiple business data models 331-33M for the same business domain. These EDMs may, for example, be located in the data service layer 330. The EDMs may be implemented, for example, in firmware or software.

[0092] Specifically, the processor 310 receives design information from multiple ISVs 401~40N. The design information indicates the requirement data of multiple business process models 341~34N, as well as requirements such as data structure. The processor 310 executes (for example, calls) multiple business data models 331~33M based on the design information of the multiple business process models 341~34N, so that the multiple business data models 331~33M respectively perform addition, deletion, query and modification on the multiple entity data models to obtain standard data that matches the design information. In other words, the multiple business data models 331~33M respectively call the corresponding entity data models through multiple APIs (i.e., "API_F1"), so that these business data models 331~33M respectively add, delete, query and modify the database table structures accessed by the corresponding multiple entity data models according to the design information. In this way, the processor 310 obtains standard data that matches the design information based on the database table structure.

[0093] In the embodiment of FIG2 , within the data service layer 330, the processor 310 accesses multiple constructed business data models 331-33M to construct a related data model 335. Specifically, the processor 310 pushes the standard data accessible by all current business data models 331-33M to the related data model 335 in real time and establishes associations between the standard data and the multiple business data models 331-33M. The related data model 335 can also be referred to as a related data hub. The related data model 335 can be implemented, for example, in firmware or software.

[0094] Furthermore, the processor 310 receives query information from multiple ISVs 401-40N. The query information indicates the definition of required data and query content, such as attribute constraints, for multiple business process models 341-34N. Based on the query information from the multiple business process models 341-34N, the processor 310 executes (e.g., calls) the associated data model 335, causing the associated data model 335 to perform a query operation on the multiple business data models 331-33M to obtain association results between the multiple business data models 331-33M. The association results may include standard data from different business domains, as well as associations between the standard data and the corresponding multiple business data models 331-33M. Specifically, the associated data model 335 calls the multiple business data models 331-33M via a corresponding API (i.e., "API_F2"), causing the associated data model 335 to query (i.e., read) the standard data accessed by these business data models 331-33M based on the query information.

[0095] It should be noted that to prevent multiple ISVs 401-40N from querying cross-business domain standard data and thus reducing the efficiency of business service system 300, business service system 300 pushes standard data from all business domains to linked data model 335 in real time and synchronously. Therefore, linked data model 335 can provide cross-business domain query services.

[0096] Figure 4 is an operational diagram of a business service system according to an embodiment of the present invention. Referring to Figure 4, the business service system 500 may include a processor 510 and a memory 520. The processor 510 is coupled to the memory 320, the end user 420, and other end users 430 (i.e., tenants) who use the business service system 500. The memory 520 stores multiple models in the data service layer 530 and multiple models in the business service layer. The processor 510 accesses the memory 520 and can execute the data in the memory 520. The various models in the memory 520 can be implemented in programming languages ​​such as JSON (JavaScript Object Notation), Extensible Markup Language (XML), or YAML, for example, but the present invention is not limited thereto. The business service system 500 can refer to the relevant description of the business service system 300 and make analogies thereto. For the sake of convenience, Figure 4 omits some components in the business service system 500.

[0097] In the embodiment of FIG4 , the business service system 500 uses a single business domain as an example to illustrate how to construct a business data model 531 corresponding to this domain (e.g., a work order domain). In this embodiment, the processor 510 accesses the end user 420 to further access one or more databases. The end user 420 may include industry enterprises, social organizations, and experts such as industry alliances. In addition, the processor 510 accesses the end user 430 to further provide data services (e.g., the constructed business data model 541) to the end user 430. The end user 430 may include an independent software vendor (ISV), a customer, and other third-party organizations.

[0098] In this embodiment, processor 510 accesses multiple databases 521-522 to obtain multiple standard fields and terminology data corresponding to different business domains. The multiple standard fields may include unified vocabulary standards such as naming, attributes, and content specifications for multiple fields with the same semantics. The terminology data may include industry terminology standards for various industries and scenarios within each business domain. The multiple standard fields and terminology data may, for example, be the standard data in step S320.

[0099] In the example of FIG4 , processor 510 accesses industry terminology library 521 to obtain terminology data corresponding to the work order field, and accesses field library 522 to obtain multiple standard fields corresponding to the work order field. Industry terminology library 521 may be, for example, a terminology library maintained by various industry experts among end users 420. Field library 522 may be, for example, a vocabulary dictionary. Field library 522 is database-oriented and manages vocabulary in a unified manner.

[0100] In this embodiment, processor 510 matches multiple standard fields in field library 522 with terminology data in industry terminology library 521 to generate mapping lexicon 523. Processor 510 stores mapping lexicon 523 in memory 520. Mapping lexicon 523 may include mapping relationships between multiple standard fields and terminology data. For example, mapping lexicon 523 may include various nomenclatures for multiple standard fields in field library 522 in different industries within the work order domain. In other words, processor 510 uses mapping lexicon 523 to translate terminology data from different industries and / or application scenarios into unified nomenclature. Mapping lexicon 523 may also be referred to as an industry vocabulary library.

[0101] Continuing with the above description, processor 510 constructs multiple entity data models (e.g., entity data model 551) based on multiple standard fields corresponding to different business domains. Processor 510 executes each of these entity data models to obtain database table structures for different business domains. Processor 510 stores the multiple entity data models in memory 520. In this embodiment, entity data model 551 is business object-oriented and is used to provide a database table structure related to work orders.

[0102] Furthermore, processor 510 performs CRUD operations on multiple entity data models (e.g., entity data model 551) based on different business domains to restrict the access scope of each of these entity data models. Specifically, processor 510 restricts the access scope of entity data model 551 through the data service (i.e., CRUD) API_F3. In this way, processor 510 can call upon entity data model 551 to perform CRUD operations on the database table structure accessed by this model 551.

[0103] In this embodiment, processor 510 constructs multiple business data models (e.g., business data models 531) corresponding to different business domains based on the image vocabulary 523 and multiple entity data models (e.g., entity data models 551) within the access scope provided by data service API_F3. That is, based on the limited open scope of each business domain, processor 510 considers the various industries and application scenarios within each business domain and constructs business data models 531 based on the naming translations in image vocabulary 523 and the data structures and attribute constraints in the corresponding entity data models 551. Business data models 531 are intended for end users 430. In this manner, processor 510 can provide business data models 531 to end users 430.

[0104] It should be noted that by standardizing data naming, data attributes, and data content through the field library 522 and the entity data model 551, the business service system 500 can achieve consistent constraints on vocabulary. In this way, the field library 522 and the entity data model 551 form the system-oriented system data standard DS1.

[0105] Furthermore, through the image vocabulary 523, the business service system 500 can present various professional and easy-to-understand naming translations. Using specialized terminology from various industries through the data service API_F3 and the business data model 531, the business service system 500 can precisely describe the target application scenario with professional and unified naming translations. Furthermore, the business service system 500 can access the attribute constraints of the application scenario and the accumulated knowledge of the industry through the business data model 531, and provide this information to the end user 430 for direct use of the business data model 531. In this way, the data service API_F3 and the business data model 531 form the business-oriented business data standard DS2.

[0106] Figure 5 is a schematic diagram of the layered architecture of the data service layer of the embodiment of Figure 4 of the present invention. Referring to Figures 4 and 5, data service layer 530 may include a data management layer 532, a data storage layer 533, a data access layer 534, and a business model layer 535. Business service system 500 utilizes the architecture of multiple layers 532-535 to provide standardized data that conforms to system data standard DS1 and business data standard DS2, thereby providing business data services.

[0107] In the data management layer 532, the business service system 500 provides the system data standard DS1. The business service system 500 may include a metadata management model 522a, a governance tool model 522b, and multiple entity data models (e.g., entity data model 551). The processor 510 executes (e.g., invokes) the metadata management model 523a to store and / or manage the field library 522 and its corresponding business types.

[0108] Furthermore, the processor 510 calls each entity data model (e.g., entity data model 551) to construct (i.e., build) and display the structure of the entity data model 551. In this embodiment, the processor 510 calls the governance tool model 522b to store and / or manage the sub-library and partitioning standards of the field library 522. The processor 510 also uses the governance tool model 522b to store and / or manage data segmentation constraints and compliance check constraints across multiple entity data models.

[0109] In the data storage layer 533, the business service system 500 may include data from various business domains. The business service system 500 may also include multiple characterization tags DT for each business domain to support different industries and application scenarios within each business domain. For example, the business service system 500 may include an inventory database D1 for the inventory domain, a procurement database D2 for the procurement domain, a work order database D3 for the work order domain, and databases D4 for other domains. The multiple characterization tags DT may include data attributes, categories, and generalizations to store terminology data and standard fields corresponding to multiple industries.

[0110] In the data access layer 534, the business service system 500 may include a permission check model 541, a model parsing model 542, a data access model 543, and a service governance model 544. The processor 510 calls the permission check model 541 to check service permissions and data permissions based on the data in the data storage layer 533. The processor 510 calls the model parsing model 542 to implement model search and message assembly based on the data in the data storage layer 533.

[0111] Furthermore, the processor 510 invokes the data access model 543 to implement CRUD operations and compliance checks based on the data in the data storage layer 533. The processor 510 invokes the service governance model 544 to implement risk control management and elastic scaling based on the data in the data storage layer 533.

[0112] In the business model layer 535, the business service system 500 provides the business data standard DS2. The business service system 500 may include multiple business data models 531-533. These business data models include, for example, a custom model 531, a business model presentation model 532, and a business model construction model 533. The processor 510 executes (e.g., calls) the custom model 531 to implement the design and solution debugging of the target model (e.g., the business process model 341 in Figure 2).

[0113] In addition, the processor 510 implements model classification, model search, and model display for the target business process model by calling the business model display model 532. The processor 510 implements standard mapping and model construction for various fields of the target business process model 341 by calling the business model construction model 533.

[0114] Figures 6A and 6B are schematic diagrams illustrating the operation of the business service system according to the embodiment of Figure 4 of the present invention. Referring to Figures 4 and 6A and 6B, processor 510 in data service layer 530 (i.e., data service processor 510) executes steps S610 to S690 to illustrate how end user 430 constructs and accesses standard data through business service system 500, and also illustrates the implementation details of steps S310 to S320.

[0115] In the embodiment of Figure 6A, the ISV in the end user 430 can call the business service system 500 in the private cloud to operate the business service system 500 in the design state. In the design state, the processor 510 executes steps S610 to S640 to construct standard data (e.g., the entity data model 551 and the corresponding business data model 531).

[0116] Specifically, in step S610, processor 510 designs entity data model 551 based on the design information provided by the ISV. Specifically, processor 510 creates database tables in data service layer 530 and uses these tables to maintain relationships between multiple models in data service layer 530. In this embodiment, data service processor 510 abstracts entity data model 551 from business data model 531 and constructs database tables based on entity data model 551.

[0117] In step S620, the processor 510 designs the business data model 531 based on the design information provided by the ISV. Based on the design information, the processor 510 constructs the business data model 531 through the API associated with the entity data model 551 (e.g., the various models 522a-522b in FIG. 5 ) and the corresponding data service (e.g., the data service API_F3 in FIG. 4 ), and thereby maintains the relationships between the multiple models in the data service layer 530.

[0118] At step S630, processor 510 configures a custom query service for business data model 531 based on the design information provided by the ISV. Specifically, based on the design information, processor 510 configures query rules for the API (e.g., data service API_F3 in FIG. 5 ) corresponding to business data model 531. Each query rule may include a corresponding solution number.

[0119] In this embodiment, the processor 510 stores at least one of the entity data model 551, the business data model 531, and the query rules generated in steps S610-S640 in the memory 520 and / or another database (e.g., the model library 624). The model library 624 may be, for example, a database included in the system management center 620a. The system management center 620a may be, for example, an application system hosted in a public cloud (e.g., the application system 411 in FIG. 2 ).

[0120] In this embodiment, the processor 510 may repeatedly execute steps S610 to S630 until the ISV completes the design of the business data model 531. In step S640, the processor 510 publishes the business data model 531 that has been designed.

[0121] 6B , the ISV in the end user 430 can call the business service system 500 in the public cloud to enable the business service system 500 to operate in the running state. In the running state, the processor 510 executes steps S650 to S690 to process standard data.

[0122] In step S650, the processor 510 calls the system management center 620a in the data service layer 530 to read the designed business data model 531. The processor 510 also accesses the business input parameters Din provided by the ISV in the data service layer 530. Based on the input parameters Din, the processor 510 parses the model parameters of the business data model 531. The business input parameters Din may include parameters such as the name of the API used to read the business data model 531 and the solution number corresponding to the query rule.

[0123] Specifically, processor 510 calls one or more APIs (API_F4-API_F5) in system management center 620a based on business input parameter Din. System management center 620a accesses the business data model 531 published in step S640 into model repository 624 via API API_F4, thereby implementing the create / update service. Furthermore, processor 510 calls API API_F4. In this way, system management center 620a accesses the business data model 531 published in step S640 into cache 525 in memory 520 via API API_F4. Processor 510 accesses cache 525 to read business data model 531.

[0124] Alternatively, the processor 510 calls the API API API_F5 in the system management center 620a. In this way, the system management center 620a directly accesses the latest published business data model 531 from the model library 624 through the API API_F5 to implement the read service.

[0125] In step S660, processor 510 assembles the business data model 531 read in step S650 and the relationship between the custom query in data service layer 530 to generate an assembly and query result. The assembly and query result indicates the data structure of business data model 531. In other words, data service processor 510 dynamically analyzes the relationship between multiple fields in business data model 531 based on the query rule in step S630.

[0126] In step S670, the processor 510 organizes the assembly and query results in step S660 into a program executable by the processor 510 in the data service layer 530. The executable program may, for example, include the business data model 531 represented by programs such as QueryInfo and / or DwDataSet. In step S680, the processor 510 executes the executable program in step S670 in the data service layer 530 in the public cloud as a decentralized autonomous organization (DAO).

[0127] In step S690, processor 510 processes the data from step S680 in data service layer 530. Specifically, data service processor 510 organizes the execution results of structured business data model 531 to generate output data Dout. Output data Dout may be, for example, standard data accessible by business data model 531. Processor 510 outputs output data Dout to end user 430.

[0128] Figures 7A to 7H are schematic diagrams of the operation of the business service system of the embodiment of Figure 4. Referring to Figure 4 and Figures 7A to 7G, the business service system 500 provides the user 430 with a user interface to operate the business service system 500 and construct standard data.

[0129] In the embodiment of Figure 7A , end user 430 invokes business service system 500 operating in the design state and selects different business domains to generate design information. For example, the design information is the work order domain indicated in block F71 . The work order domain encompasses work orders from various industries. Work orders may include equipment assembly work orders and parts batch production work orders.

[0130] In the embodiment of FIG7B , end user 430 selects a data source to create one or more business data models (e.g., business data model 531) for the work order domain. The data source may be, for example, the associated data model for the work order domain indicated in block F72. End user 430 can construct different work order models (i.e., multiple business data models) from different industry perspectives.

[0131] In the embodiment of FIG7C , the end user 430 selects one or more source work order entity data models (e.g., entity data model 551 ) to be applied to multiple business data models according to the required business scenario. The selected entity data models may include a work order entity model, a work order requirement entity model, and a work order detail entity model.

[0132] In the embodiment of FIG7D , end user 430 constructs multiple business data models based on the various entity data models selected in FIG7C . Thus, these business data models can be applied from different industry perspectives and in different business scenarios. In the embodiment of FIG7E , end user 430 confirms the multiple business data models constructed in FIG7D .

[0133] 7F , end user 430 accesses terminology repository 521 through business service system 500. End user 430 confirms to maintain terminology (ie, terminology data) for various industries.

[0134] In the embodiment of FIG7G , end user 430 binds industry terminology data to standard fields in business service system 500. In other words, end user 430 confirms matching results between multiple standard fields and terminology data. The matching results can be stored in image word library 523, for example.

[0135] In the embodiment of FIG7H , end user 430 sequentially constructs multiple business data models from different industry perspectives and in different business scenarios. These business data models are applied to the work order field for equipment assembly orders. These business data models may include an assembly work order model from a production management perspective, an assembly work order model from a finance perspective, and an assembly work order model from a warehouse management perspective.

[0136] Figure 8 is a schematic diagram of the operation of a business data model according to an embodiment of the present invention. Referring to Figure 8 , the business service system 900 can refer to the relevant description of the business service system 300 and be deduced by analogy. For ease of description, Figure 8 omits some components in the business service system 900.

[0137] In the embodiment of FIG8 , end users construct, access, and / or invoke multiple business data models through the business service system 900. These business data models may include, for example, a standard work order business model 931 common to all ISVs, a custom work order business model 932 developed by a first ISV (i.e., “ISV1”), and a custom work order business model 933 developed by a second ISV (i.e., “ISV2”).

[0138] In this embodiment, the business service system 900 executes multiple business data models 931-933 to access a database via a data service API_F3 (e.g., a CURD access service API_F31 for work orders). The aforementioned database may be, for example, a database in the work order domain, storing work order data D3 and multiple characterization tags DT, as shown in FIG5 . The database may include a work order database D5 and an entity data model 951.

[0139] Referring to Figures 9A and 9B , Figure 9A is a schematic diagram of the application of the business data model of the embodiment of Figure 8 of the present invention. Figure 9B is a schematic diagram of the application of the entity data model of the embodiment of Figure 8 of the present invention. The business data model 931 common to each ISV may include business structures such as general work order information and work order material information, as well as data content corresponding to the business structure and attribute constraints. The business data model 932 developed by the first ISV (i.e., "ISV1") may include business structures such as general work order information, multiple work order output information, and work order material information, as well as data content corresponding to the business structure and attribute constraints.

[0140] In the embodiment of Figure 9A , compared to business data model 931, field F101 includes another attribute constraint regarding "estimated production." Furthermore, compared to business data model 931, field F102 includes additional data regarding "work order material information." In other words, the multiple business data models 931-932 are business models constructed based on data content specific to different business needs, rather than being structured as database table fields.

[0141] In the embodiment of Figure 9B , entity data model 951 may include a database table structure for a work order header table corresponding to various standard fields. Another entity data model 952 may include a database table structure for a work order detail table corresponding to various standard fields. Entity data model 953 may include a database table structure for a work order multi-output table corresponding to various standard fields. In other words, the system's multiple entity data models 951-953 are entity models constructed based on "work order" data.

[0142] Returning to the embodiment of FIG8 , it should be noted that the multiple business data models 931 to 933 can serve as a conversion layer between data (e.g., the work order database D5) and end users. When operating the business service system 900, the end user does not need to be concerned with the technical complexity and implementation of the underlying system. The end user can organize (i.e., construct) the corresponding business data models 931 to 933 in the language of their own industry so that other end users in the same industry can understand the business language presented by the business service system 900.

[0143] In other words, by converting complex data structures in the database into business language understandable to end users through each business data model 931-933, the business service system 900 can visualize each business data model 931-933, thereby improving the convenience and efficiency of query services. Furthermore, by executing the encapsulated CURD access service API_F31 through each business data model 931-933, the business service system 900 can achieve a more personalized model design for end users and reduce the complexity of the processing logic of each business data model 931-933.

[0144] In summary, the business service system and the method for executing business services of the present invention are applicable to the business middle platform, and realize the innovative architecture in which business services (i.e., multiple business processing models) and business data (i.e., multiple business data models) are separated. By sharing multiple business data models, the business service system can uniformly constrain the standard data facing the system, thereby avoiding integration and confusion between data. Therefore, the business service system can construct multiple business data models that are close to the needs of end users in a professional industry language and data structure. In addition, by calling the service operations of the data service layer to obtain various standard data, the business service system can avoid end users directly accessing the database table, thereby ensuring storage security. By sharing multiple business data models, the business service system can provide different end users with multiple business processing models that are built by each other and shared with each other. Therefore, the business service system avoids the concentration of resources in their respective field centers, and also avoids end users from building duplicate business data, thereby reducing development costs.

[0145] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or perform equivalent replacements on some or all of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A business service system, characterized in that: include: Memory; as well as The processor is coupled to the memory and performs the following operations: In the data service layer, multiple business data models are constructed based on the memory. Executing the plurality of business data models to call the memory to respectively obtain standard data corresponding to different business fields, The plurality of business data models are shared in the data service layer, and a plurality of business processing models are constructed in the business service layer according to the plurality of business data models, and The multiple business processing models are executed to call the multiple business data models to respectively provide different business services to the corresponding multiple tenants.

2. The business service system according to claim 1, characterized in that: The memory stores a plurality of entity data models corresponding to different business domains, wherein the processor further performs the following operations: According to the design information of the multiple business process models, the multiple business data models are executed to respectively perform addition, deletion, query and modification on the multiple entity data models to obtain the standard data matching the design information.

3. The business service system according to claim 1, characterized in that: The processor also performs the following operations: In the data service layer, accessing the plurality of business data models to construct a related data model, and The association data model is executed according to the query information of the multiple business processing models to perform a query operation on the multiple business data models to obtain association results between the multiple business data models.

4. The business service system according to claim 1, characterized in that: The processor also performs the following operations: Access multiple databases to obtain multiple standard fields and terminology data corresponding to different business areas, matching the plurality of standard fields and the terminology data to generate a mapping vocabulary, and The mapping vocabulary is stored in the memory.

5. The business service system according to claim 4, characterized in that: The processor also performs the following operations: Construct multiple entity data models according to the multiple standard fields corresponding to different business areas. Execute the multiple entity data models to obtain database table structures of different business domains, and The plurality of entity data models are stored in the memory.

6. The business service system according to claim 5, characterized in that: The processor also performs the following operations: According to different business areas, the plurality of entity data models are added, deleted, checked and modified to limit the access scope of the plurality of entity data models respectively, and In the access scope, the plurality of business data models corresponding to different business domains are respectively constructed according to the mapping vocabulary and the plurality of entity data models.

7. A method for executing a business service, characterized in that: include: Through the processor, in the data service layer, multiple business data models are built based on the memory; executing the plurality of business data models through the processor to call the memory to respectively obtain standard data corresponding to different business fields; Sharing the multiple business data models in the data service layer, and constructing multiple business processing models in the business service layer according to the multiple business data models, by the processor; as well as The processor executes the multiple business processing models to call the multiple business data models to provide different business services to the corresponding multiple tenants.

8. The method for executing business services according to claim 7, wherein: Also includes: The processor executes the multiple business data models according to the design information of the multiple business process models, so as to perform addition, deletion, query and modification on multiple entity data models corresponding to different business fields to obtain the standard data matching the design information.

9. The method for executing business services according to claim 7, wherein: Also includes: Accessing, by the processor, in the data service layer, the plurality of business data models to construct a related data model; as well as The processor executes the association data model according to the query information of the multiple business processing models, so as to perform a query operation on the multiple business data models to obtain association results between the multiple business data models.

10. The method for executing business services according to claim 7, wherein: Also includes: Accessing, by the processor, multiple databases to obtain multiple standard fields and terminology data corresponding to different business areas; By the processor, matching the plurality of standard fields and the terminology data to generate a mapping vocabulary; as well as The mapping vocabulary is stored in the memory via the processor.

11. The method for executing business services according to claim 10, characterized in that: Also includes: By means of the processor, a plurality of entity data models are constructed respectively according to the plurality of standard fields corresponding to different business areas; Executing the plurality of entity data models to obtain database table structures of different business domains through the processor; as well as The processor stores the plurality of entity data models in the memory.

12. The method for executing business services according to claim 11, characterized in that: Also includes: By means of the processor, adding, deleting, checking and modifying the plurality of entity data models are performed according to different business domains to limit access scopes of the plurality of entity data models respectively; as well as The processor constructs, within the access scope, the plurality of business data models corresponding to different business domains according to the mapping vocabulary and the plurality of entity data models.

Images