WO2012075623A1 - Configuring master data based upon scenarios - Google Patents
Configuring master data based upon scenarios Download PDFInfo
- Publication number
- WO2012075623A1 WO2012075623A1 PCT/CN2010/079529 CN2010079529W WO2012075623A1 WO 2012075623 A1 WO2012075623 A1 WO 2012075623A1 CN 2010079529 W CN2010079529 W CN 2010079529W WO 2012075623 A1 WO2012075623 A1 WO 2012075623A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- master data
- user
- fields
- scenario
- list
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/211—Schema design and management
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Definitions
- the technical field relates generally to master data, and more particularly to using master data in software applications.
- a master data is a kind of a reference data (common data), e.g., an organization data, an account data, a business process data, etc., that may be used in various software applications (e.g., business applications).
- the master data may be defined by a metadata that is stored as a persistent or static data in a storage medium, e.g., a database, a file, etc.
- a developer can reuse or share the master data (defined by the metadata) in various software applications.
- a master data hub Several systems are available for reusing or sharing the master data in various software applications, e.g., a master data hub.
- the developer can retrieve the master data and use the retrieved master data in several applications, if required. For example, if the developer wants to create two different applications, e.g., a process control and an access control, the developer can retrieve the master data that is common to both the process control and the access control and reuse the master data in both these applications.
- the master data hub stores the master data that is common to both the applications so that it can be reused. The common master data behaves exactly the same in both the applications.
- the behavior of the master data is defined by its metadata.
- the metadata of the master data is stored and maintained in a persistence or static layer, e.g., the database and/or the file of the master data hub (central server).
- the developers can retrieve the master data (e.g., defined by the metadata stored in the server) for developing the software application.
- the developers can retrieve the master data (e.g., defined by the metadata stored in the server) for developing the software application.
- the developers reuse the master data.
- a master data configuration tool is installed on a computer system to render a list of predefined master data, receive a user's selection of a master data from the list of predefined master data, display a list of scenarios defined for the selected master data, receive a user's selection of a scenario from the list of scenarios, and configure the master data based upon the user selected scenario.
- the configuration of master data based upon the scenario, selected or defined by the user makes the system very flexible, efficient, and user friendly. Further, the configuration/modification of the master data as per the requirement of the application (e.g., scenario) saves time and energy of the user (e.g., developer) in developing the application.
- FIG. 1 is a block diagram of a system including a master data configuration tool for configuring master data based upon a scenario, according to an embodiment.
- FIG. 2 is a block diagram illustrating an exemplary list of predefined master data, according to an embodiment.
- FIG. 3 is a block diagram illustrating an exemplary master data, according to an embodiment.
- FIG. 4 is a block diagram illustrating an exemplary list of scenarios defined for the master data, according to an embodiment.
- FIG. 5 is a block diagram illustrating an exemplary screen display of the master data of FIG. 3 configured according to a scenario defined by a user.
- FIG. 6 is a block diagram illustrating an exemplary screen display of the master data of FIG. 3 configured according to another scenario defined by the user.
- FIG. 7 is a flow diagram for dynamically generating the master data, according to an embodiment.
- FIGs. 8 A-B is a block diagram illustrating a metadata including various tables for defining the master data, according to an embodiment.
- FIG. 9 is a flow diagram illustrating the steps performed to configure the master data based upon the scenario, according to various embodiments.
- FIG. 10 is a block diagram of an exemplary computer system, according to an embodiment.
- FIG. 1 illustrates one embodiment comprising a system 100 including a master data configuration tool 110 for configuring master data 120(1) based upon a scenario 130.
- the master data configuration tool 110 is installed on a computer system 140 (e.g., a central server) to render a list of predefined master data 200 (refer to FIG. 2).
- the list of predefined master data 200 includes a plurality of master data 120 (1-n).
- a user selects the master data 120(1) from the list of predefined master data 200.
- the master data configuration tool 110 displays a list of scenarios (not shown) defined for the master data 120(1).
- the user selects the scenario 130 from the list of scenarios and the master data configuration tool 110 configures the master data 120(1) based upon the scenario 130.
- the master data 120(1) is customized based upon the scenario 130.
- the scenario 130 may be defined by the user.
- the user may define the scenario 130 by setting a property of one or more fields FLD1-FLD13 (refer to FIG. 3) of the master data 120(1).
- the master data 120(1) comprises one or more tabs (e.g., tab 1 and tab 2).
- Each tab e.g., tab 1 and tab 2) organizes a common group of data related to the master data 120(1).
- tab 1 generally
- tab 2 risks
- Each tab (e.g., tab 1 and tab 2) comprises one or more UIBB (User Interface Building Block) to control the display of the tab.
- UIBB User Interface Building Block
- tab 1 (general) includes a UIBB 1 to display 'key' or 'required' information related to the master data 120(1) and UIBB 2 to display 'customer's (end user's) comments' related to the master data 120(1).
- Each UIBB (1-2) includes one or more fields.
- UIBB 1 of tab 1 includes the fields (FLD1-FLD12) and UIBB 2 includes the field FLD13.
- Each field (FLD1-FLD13) has a label/title (e.g., name, description, control or process step, control category, etc) and the property associated with it.
- the property of the fields may comprise one of characteristic selected from a group of hidden, display only, optional, and required.
- the property of the fields (FLD1-FLD13) regulates the behavior of the fields (FLD1-FLD13). For example, if the property of the field FLD13 (labeled: control long text) is 'hidden' then the field FLD13 would not be displayed on a user interface, if the property of the field FLD1 (labeled: name) is 'display only' then the end user cannot modify the value of the field FLD1.
- the end user has to provide the value of the field FLD1 (i.e., the field FLD1 cannot be blank).
- the end user customer may or may not set the value of the field FLD1 (i.e., the field FLD1 can be blank).
- the property of the fields (FLD1-FLD13) may be set by the user (e.g., developer) to define the scenario 130.
- FIG. 4 illustrates various scenarios 130 (1-3) that may be defined for an exemplary master data 120(1) (i.e., control).
- the exemplary master data 120(1) may comprise the fields FLD1-FLD2 and FLD13-FLD15.
- the property of the fields FLD (1-2) and FLD (13-15) may be set by the user to define each scenario 130 (1- 3).
- the scenario 130(1) may be defined by setting the property of the fields FLD1, FLD2, and FLD 14 as 'required', field FLD 13 as 'display only', and field FLD 15 as 'optional'
- the scenario 130(2) may be defined by setting the property of the fields FLD1 and FLD14 as 'required', and fields FLD(2, 13, and 15) as 'optional'
- the scenario 130(3) may be defined by setting the property of the field FLD1 as 'required', field FLD2 as 'optional', and fields FLD13-FLD15 as 'hidden', as illustrated in FIG. 4.
- the scenarios 130 (1-3) may be defined based upon the requirement of the application, to be developed by the user.
- the user may define the scenario 130 for the master data 120(1) (refer to
- FIG. 3 by setting the property of the fields FLD1-FLD13.
- the master data 120(1) is configured and rendered.
- the configuration (behavior) of master data 120(1) is scenario dependent. For example, if the user wishes to develop the application 'process control', that only requires the fields FLD (1-3) and FLD (7-12) in tab 1 (general tab) of the master data 120(1).
- the user may sets the properties of the fields FLD (4-6 and 13) of the master data 120(1) as 'hidden' to define the scenario (not shown) for the 'process control'.
- a master data variant 500 (refer to FIG. 5) may be generated.
- the generated master data variant 500 may be used in process control. Similarly, if the user wishes to develop the application 'access control', that requires the fields FLD (1-2) and FLD (8-9) in tab 1 (general tab) of the master data 120(1). The user may set the properties of the fields FLD (3-7 and 10-13) of the master data 120(1) as 'hidden' to define the scenario (not shown) for the 'access control'. Based upon the defined scenario, the master data variant 600 (refer to FIG. 6) may be generated. The generated master data variant 600 may be used in access control. Essentially, the user defines different scenarios for generating different variants of the master data 120(1), to be used in different applications. Therefore, the master data 120(1) behaves (renders) differently for the 'process control' 500 and the 'access control' 600 (as illustrated in FIGs. 5-6).
- the master data 120(1) is configured based upon the scenarios defined for 'process control' and 'access control' .
- the master data variant 500 (used in process control) and the master data variant 600 (used in access control) are generated based upon the respective scenario defined for them.
- the master data variant 500 or the master data variant 600 may be generated dynamically, based upon the respective scenario defined for them.
- the master data configuration tool 110 employs a generation logic 710 (refer to FIG. 7) to dynamically generate and render the configured master data 120(1) on the user interface, based upon the scenario.
- the generation logic 710 refers to a metadata 800 (refer to FIGs.
- the metadata 800 is maintained as various tables 810 (A-I) related to the components (tabs, UIBBs, and fields) of the master data 120(1). Essentially, each component (tab, UIBB, and fields) of the master data 120(1) is defined by the metadata 800.
- the metadata 800 may be defined using XML (extensible markup language), RDBMS (relational database) tables, etc.
- the tables 810 define various components (tabs, UIBBs, and fields) of the master data 120(1).
- the table 810G FLD (refer to FIG. 8B) defines the characteristic of the fields, e.g., a category of the fields where the field is stored CATEGORY (e.g., database or file, etc), whether the customer can change the configuration of the field (TO CUSTOMIZE), the type of data of the field like alphabet, numeral value, etc., (DATAELEMENT), optional handler class name (FLD HANDLER), i.e., if the field has a FLD handler then further metadata are defined for the field, i.e., the field is further extensible.
- CATEGORY e.g., database or file, etc
- TO CUSTOMIZE the type of data of the field like alphabet, numeral value, etc.
- DATAELEMENT optional handler class name
- FLD HANDLER optional handler class name
- the metadata 800 also includes the table 81 OH (FLDDB) that indicates a name of the table (TAB NAME) if the field FLD is located in the database. Similarly, the metadata 800 may also include the table 8101 (FLDFILE) to indicate a name of the file (FILENAME) if the field is located in the file. Essentially, the metadata 800 includes the tables 810 (A-I) to define various components of the master data 120(1). [0030] The metadata 800 (including tables 810 (A-I)) may be referred by the generation logic 710 to first generate the tabs (tab 1 and tab 2) of the master data 120(1).
- the generation logic 710 refers to the tables 810A (ENTTAB) and 810B (TAB) (refer to FIG. 8A) to retrieve the information related to the tabs, e.g., tab ID, a sequence of the tab (e.g., the sequence of the tab 1 or general tab would be first, the sequence of the tab 2 or risk tab would be second), title of tabs (e.g., tab 1 : general and tab 2: risks), etc. Based upon the information of the tabs, the generation logic 710 generates the tabs (tab 1 and tab 2) of the configured master data 120(1).
- the generation logic 710 generates the user interface 730(a) to illustrate the tab 1 (titled: general) and tab 2 (titled: risks) of the configured master data 120(1).
- the generation logic 710 refers to the tables 8 IOC (TABUIBB) and 810D (UIBB) (refer to FIG. 8 A) to retrieve the information related to the UIBBs of each tabs (e.g., UIBB 1 and UIBB 2 of the tab 1).
- the information related to UIBBs including ID of UIBB related to the tab, sequence of UIBB (e.g., UIBB 1 should be above or at the top of UIBB 2, etc), UIBB title etc.
- the generation logic 710 Based upon the information, the generation logic 710 generates the UIBB for the tabs (1-2). For example, the generation logic 710 generates the UIBB1 and UIBB2 for tab 1. Essentially, the generation logic 710 generates the user interface 730(b) to illustrate the UIBB of the tabs. Once the UIBBs are generated, the generation logic 710 refers the tables 810E (UIBBFLD), 81 OF (FLDSCENARIO), and 810G (FLD) (refer to FIGs. 8A-8B) to retrieve the information related to the fields of the UIBBs (e.g., fields FLD1 of the UIBB1 and FLD2 of the UIBB2, as illustrated in FIG. 7).
- the generation logic 710 refers the tables 810E (UIBBFLD), 81 OF (FLDSCENARIO), and 810G (FLD) (refer to FIGs. 8A-8B) to retrieve the information related to the fields of the UIBBs (e.g
- the information like field ID, scenario, property of the field in the scenario, whether the field is customizable (customer can change the value of the field), etc., may be retrieved from the metadata 800.
- the generation logic 710 Based upon the information, the generation logic 710 generates the fields, e.g., FLD1 for the UIBB1 and FLD 2 for the UIBB 2, as illustrated in FIG. 7. Essentially, the generation logic 710 generates the user interface 730(c) to illustrate the fields FLD1-FLD2 of the UIBB 1 and fields of the UIBB 2 (not shown). Essentially, the generation logic 710 dynamically generates and renders the configured master data 120(1).
- the user can create a new or user defined master data (not shown).
- the master data configuration tool 110 provides an option to generate the user defined master data or to modify the predefined master data 120(1).
- the master data configuration tool 110 displays an icon (e.g., 'modify', 'update', etc) to modify the predefined master data 120(1).
- an icon e.g., 'modify', 'update', etc
- various components tab, UIBBs, and fields
- the master data configuration tool 110 displays an icon ('new', 'generate new', 'create new', etc) for generating the new (user defined) master data.
- the master data configuration tool 110 provides an option to define tabs, UIBBs, and one or more fields for the new master data.
- the fields may be defined by either selecting one or more fields from a plurality of predefined fields (not shown) or by creating one or more new fields.
- a new field may be created by selecting an icon ('add new field', 'generate field', 'create field', etc) displayed on the master data configuration tool 110. Once the icon, e.g., 'create field' is selected, various information related to the field, e.g., field name, category (db, file, etc), property (hidden, display only, optional, and required), etc., may be set by the user.
- the new field may be generated by selecting and modifying the existing field.
- the new field (user defined field) can be associated with the existing master data 120(1).
- FIG. 9 is a flowchart illustrating a method for configuring the master data 120(1) based upon the scenario 130 using the master data configuration tool 110.
- the master data configuration tool 110 renders the list of predefined master data 200 on the computer system 140 at step 901.
- the user selects the master data 120(1) to be used in the application developed by the user and the master data configuration tool 110 receives the user's selection of the master data 120(1) at step 902.
- the master data configuration tool 110 displays the list of scenarios defined for the selected master data 120(1) at step 903.
- the master data configuration tool 110 receives the user selection of the scenario 130 from the list of scenarios at step 904.
- the master data configuration tool 110 configures the master data 120(1) based upon the scenario 130 selected by the user at step 905.
- master data configuration tool 1 10 makes it possible to customize the master data 120(1), based upon the scenario 130.
- Some embodiments of the invention may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments of the invention may include remote procedure calls being used to implement one or more of these components across a distributed programming environment.
- a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface).
- interface level e.g., a graphical user interface
- first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration.
- the clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
- the above-illustrated software components are tangibly stored on a computer readable storage medium as instructions.
- the term "computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions.
- the term "computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein.
- Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits ("ASICs"), programmable logic devices ("PLDs”) and ROM and RAM devices.
- Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter.
- an embodiment of the invention may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the invention may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
- FIG. 10 is a block diagram of an exemplary computer system 1000.
- the computer system 1000 includes a processor 1005 that executes software instructions or code stored on a computer readable storage medium 1055 to perform the above-illustrated methods of the invention.
- the computer system 1000 includes a media reader 1040 to read the instructions from the computer readable storage medium 1055 and store the instructions in storage 1010 or in random access memory (RAM) 1015.
- the storage 1010 provides a large space for keeping static data where at least some instructions could be stored for later execution.
- the stored instructions may be further compiled to generate other representations of the instructions and dynamically stored in the RAM 1015.
- the processor 1005 reads instructions from the RAM 1015 and performs actions as instructed.
- the computer system 1000 further includes an output device 1025 (e.g., a display) to provide at least some of the results of the execution as output including, but not limited to, visual information to users and an input device 1030 to provide a user or another device with means for entering data and/or otherwise interact with the computer system 1000.
- an output device 1025 e.g., a display
- an input device 1030 to provide a user or another device with means for entering data and/or otherwise interact with the computer system 1000.
- Each of these output devices 1025 and input devices 1030 could be joined by one or more additional peripherals to further expand the capabilities of the computer system 1000.
- a network communicator 1035 may be provided to connect the computer system 1000 to a network 1050 and in turn to other devices connected to the network 1050 including other clients, servers, data stores, and interfaces, for instance.
- the modules of the computer system 1000 are interconnected via a bus 1045.
- Computer system 1000 includes a data source interface 1020 to access data source 1060.
- the data source 1060 can be accessed via one or more abstraction layers implemented in hardware or software.
- the data source 1060 may be accessed by network 1050.
- the data source 1060 may be accessed via an abstraction layer, such as, a semantic layer.
- a data source is an information resource.
- Data sources include sources of data that enable data storage and retrieval.
- Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like.
- Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like.
- Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like.
- a data source is an information resource.
- Data sources include sources of data that enable data storage and retrieval.
- Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like.
- Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open Database Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like.
- Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- User Interface Of Digital Computer (AREA)
Abstract
Various embodiments of systems and methods for configuring a master data based upon a scenario are described herein. A method includes rendering a list of predefined master data, receiving a user's selection of a master data from the list of predefined master data, displaying a list of scenarios defined for the selected master data, receiving a user's selection of a scenario from the list of scenarios, and configuring the master data based upon the user selected scenario. The configuration of master data based upon the scenario, selected or defined by the user, makes the system very flexible, efficient, and user friendly. Further, the modification/configuration of the master data as per the requirement of the application (scenario) saves time and energy of the user (developer) in developing the application.
Description
CONFIGURING MASTER DATA BASED UPON SCENARIOS
FIELD
[0001] The technical field relates generally to master data, and more particularly to using master data in software applications.
BACKGROUND
[0002] A master data is a kind of a reference data (common data), e.g., an organization data, an account data, a business process data, etc., that may be used in various software applications (e.g., business applications). The master data may be defined by a metadata that is stored as a persistent or static data in a storage medium, e.g., a database, a file, etc. Essentially, a developer can reuse or share the master data (defined by the metadata) in various software applications.
[0003] Several systems are available for reusing or sharing the master data in various software applications, e.g., a master data hub. Usually, in these systems, the developer can retrieve the master data and use the retrieved master data in several applications, if required. For example, if the developer wants to create two different applications, e.g., a process control and an access control, the developer can retrieve the master data that is common to both the process control and the access control and reuse the master data in both these applications. Essentially, the master data hub stores the master data that is common to both the applications so that it can be reused. The common master data behaves exactly the same in both the applications.
[0004] The behavior of the master data is defined by its metadata. The metadata of the master data is stored and maintained in a persistence or static layer, e.g., the database and/or the file of the master data hub (central server). The developers can retrieve the master data (e.g., defined by the metadata stored in the server) for developing the software application. Typically, if the developer requires the master data, as defined by the metadata of the central server, the developers reuse the master data.
[0005] However, it may be difficult for the developer to modify (customize) the behavior (some features) of the master data according to the specific requirement of the application. Further, it may be troublesome and time consuming to start from scratch and write codes for developing the master data as per the requirement of the application
(scenario). Additionally, the developer may have to build a user interface (UI) and/or business process to modify the behavior of the master data. Moreover, the inflexibility (rigidity) of the conventional systems makes it difficult for the developer to extend the master data with new features
[0006] It would be desirable, therefore, to provide a system and method for configuring master data based upon a scenario that obviates the above mentioned problems.
SUMMARY OF THE INVENTION
[0007] Various embodiments of systems and methods for configuring master data based upon a scenario are described herein. In one aspect, a master data configuration tool is installed on a computer system to render a list of predefined master data, receive a user's selection of a master data from the list of predefined master data, display a list of scenarios defined for the selected master data, receive a user's selection of a scenario from the list of scenarios, and configure the master data based upon the user selected scenario. The configuration of master data based upon the scenario, selected or defined by the user, makes the system very flexible, efficient, and user friendly. Further, the configuration/modification of the master data as per the requirement of the application (e.g., scenario) saves time and energy of the user (e.g., developer) in developing the application.
[0008] These and other benefits and features of embodiments of the invention will be apparent upon consideration of the following detailed description of preferred embodiments thereof, presented in connection with the following drawings. BRIEF DESCRIPTION OF THE DRAWINGS
[0009] The claims set forth the embodiments of the invention with particularity.
The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments of the invention, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
[0010] FIG. 1 is a block diagram of a system including a master data configuration tool for configuring master data based upon a scenario, according to an embodiment.
[0011] FIG. 2 is a block diagram illustrating an exemplary list of predefined master data, according to an embodiment.
[0012] FIG. 3 is a block diagram illustrating an exemplary master data, according to an embodiment.
[0013] FIG. 4 is a block diagram illustrating an exemplary list of scenarios defined for the master data, according to an embodiment.
[0014] FIG. 5 is a block diagram illustrating an exemplary screen display of the master data of FIG. 3 configured according to a scenario defined by a user.
[0015] FIG. 6 is a block diagram illustrating an exemplary screen display of the master data of FIG. 3 configured according to another scenario defined by the user.
[0016] FIG. 7 is a flow diagram for dynamically generating the master data, according to an embodiment.
[0017] FIGs. 8 A-B is a block diagram illustrating a metadata including various tables for defining the master data, according to an embodiment.
[0018] FIG. 9 is a flow diagram illustrating the steps performed to configure the master data based upon the scenario, according to various embodiments.
[0019] FIG. 10 is a block diagram of an exemplary computer system, according to an embodiment.
DETAILED DESCRIPTION
[0020] Embodiments of techniques for configuring master data based upon a scenario are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
[0021] Reference throughout this specification to "one embodiment", "this embodiment" and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one
embodiment of the present invention. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0022] FIG. 1 illustrates one embodiment comprising a system 100 including a master data configuration tool 110 for configuring master data 120(1) based upon a scenario 130. The master data configuration tool 110 is installed on a computer system 140 (e.g., a central server) to render a list of predefined master data 200 (refer to FIG. 2). The list of predefined master data 200 includes a plurality of master data 120 (1-n). A user selects the master data 120(1) from the list of predefined master data 200. The master data configuration tool 110 displays a list of scenarios (not shown) defined for the master data 120(1). The user selects the scenario 130 from the list of scenarios and the master data configuration tool 110 configures the master data 120(1) based upon the scenario 130. Essentially, the master data 120(1) is customized based upon the scenario 130.
[0023] The scenario 130 may be defined by the user. The user may define the scenario 130 by setting a property of one or more fields FLD1-FLD13 (refer to FIG. 3) of the master data 120(1). Essentially, the master data 120(1) comprises one or more tabs (e.g., tab 1 and tab 2). Each tab (e.g., tab 1 and tab 2) organizes a common group of data related to the master data 120(1). For example, tab 1 (general) includes general information related to the master data 120(1), while tab 2 (risks) includes information related to risks of the master data 120(1). Each tab (e.g., tab 1 and tab 2) comprises one or more UIBB (User Interface Building Block) to control the display of the tab. For example, tab 1 (general) includes a UIBB 1 to display 'key' or 'required' information related to the master data 120(1) and UIBB 2 to display 'customer's (end user's) comments' related to the master data 120(1). Each UIBB (1-2) includes one or more fields. For example, UIBB 1 of tab 1 includes the fields (FLD1-FLD12) and UIBB 2 includes the field FLD13. Each field (FLD1-FLD13) has a label/title (e.g., name, description, control or process step, control category, etc) and the property associated with it.
[0024] The property of the fields (FLD1-FLD13) may comprise one of characteristic selected from a group of hidden, display only, optional, and required. Essentially, the property of the fields (FLD1-FLD13) regulates the behavior of the fields (FLD1-FLD13). For example, if the property of the field FLD13 (labeled: control long text) is 'hidden' then the field FLD13 would not be displayed on a user interface, if the
property of the field FLD1 (labeled: name) is 'display only' then the end user cannot modify the value of the field FLD1. Alternately, if the property of the field FLD1 is 'required' then the end user has to provide the value of the field FLD1 (i.e., the field FLD1 cannot be blank). Whereas if the property of the field FLD1 is 'optional' then the end user (customer) may or may not set the value of the field FLD1 (i.e., the field FLD1 can be blank). The property of the fields (FLD1-FLD13) may be set by the user (e.g., developer) to define the scenario 130.
[0025] FIG. 4 illustrates various scenarios 130 (1-3) that may be defined for an exemplary master data 120(1) (i.e., control). The exemplary master data 120(1) may comprise the fields FLD1-FLD2 and FLD13-FLD15. Essentially, the property of the fields (FLD (1-2) and FLD (13-15)) may be set by the user to define each scenario 130 (1- 3). For example, the scenario 130(1) may be defined by setting the property of the fields FLD1, FLD2, and FLD 14 as 'required', field FLD 13 as 'display only', and field FLD 15 as 'optional', the scenario 130(2) may be defined by setting the property of the fields FLD1 and FLD14 as 'required', and fields FLD(2, 13, and 15) as 'optional'. The scenario 130(3) may be defined by setting the property of the field FLD1 as 'required', field FLD2 as 'optional', and fields FLD13-FLD15 as 'hidden', as illustrated in FIG. 4. Essentially, the scenarios 130 (1-3) may be defined based upon the requirement of the application, to be developed by the user.
[0026] The user may define the scenario 130 for the master data 120(1) (refer to
FIG. 3) by setting the property of the fields FLD1-FLD13. Essentially, based upon the property of the fields FLD1-FLD13 (i.e., scenario 130), the master data 120(1) is configured and rendered. Typically, the configuration (behavior) of master data 120(1) is scenario dependent. For example, if the user wishes to develop the application 'process control', that only requires the fields FLD (1-3) and FLD (7-12) in tab 1 (general tab) of the master data 120(1). The user may sets the properties of the fields FLD (4-6 and 13) of the master data 120(1) as 'hidden' to define the scenario (not shown) for the 'process control'. Based upon the defined scenario, a master data variant 500 (refer to FIG. 5) may be generated. The generated master data variant 500 may be used in process control. Similarly, if the user wishes to develop the application 'access control', that requires the fields FLD (1-2) and FLD (8-9) in tab 1 (general tab) of the master data 120(1). The user may set the properties of the fields FLD (3-7 and 10-13) of the master data 120(1) as 'hidden' to define the scenario (not shown) for the 'access control'. Based upon the
defined scenario, the master data variant 600 (refer to FIG. 6) may be generated. The generated master data variant 600 may be used in access control. Essentially, the user defines different scenarios for generating different variants of the master data 120(1), to be used in different applications. Therefore, the master data 120(1) behaves (renders) differently for the 'process control' 500 and the 'access control' 600 (as illustrated in FIGs. 5-6).
[0027] Essentially, the master data 120(1) is configured based upon the scenarios defined for 'process control' and 'access control' . The master data variant 500 (used in process control) and the master data variant 600 (used in access control) are generated based upon the respective scenario defined for them. The master data variant 500 or the master data variant 600 may be generated dynamically, based upon the respective scenario defined for them. Essentially, the master data configuration tool 110 employs a generation logic 710 (refer to FIG. 7) to dynamically generate and render the configured master data 120(1) on the user interface, based upon the scenario.
[0028] Typically, the generation logic 710 refers to a metadata 800 (refer to FIGs.
8A-8B) that defines the master data 120(1). The metadata 800 is maintained as various tables 810 (A-I) related to the components (tabs, UIBBs, and fields) of the master data 120(1). Essentially, each component (tab, UIBB, and fields) of the master data 120(1) is defined by the metadata 800. The metadata 800 may be defined using XML (extensible markup language), RDBMS (relational database) tables, etc.
[0029] The tables 810 (A-I) define various components (tabs, UIBBs, and fields) of the master data 120(1). For example, the table 810G FLD (refer to FIG. 8B) defines the characteristic of the fields, e.g., a category of the fields where the field is stored CATEGORY (e.g., database or file, etc), whether the customer can change the configuration of the field (TO CUSTOMIZE), the type of data of the field like alphabet, numeral value, etc., (DATAELEMENT), optional handler class name (FLD HANDLER), i.e., if the field has a FLD handler then further metadata are defined for the field, i.e., the field is further extensible. The metadata 800 also includes the table 81 OH (FLDDB) that indicates a name of the table (TAB NAME) if the field FLD is located in the database. Similarly, the metadata 800 may also include the table 8101 (FLDFILE) to indicate a name of the file (FILENAME) if the field is located in the file. Essentially, the metadata 800 includes the tables 810 (A-I) to define various components of the master data 120(1).
[0030] The metadata 800 (including tables 810 (A-I)) may be referred by the generation logic 710 to first generate the tabs (tab 1 and tab 2) of the master data 120(1). Essentially, the generation logic 710 refers to the tables 810A (ENTTAB) and 810B (TAB) (refer to FIG. 8A) to retrieve the information related to the tabs, e.g., tab ID, a sequence of the tab (e.g., the sequence of the tab 1 or general tab would be first, the sequence of the tab 2 or risk tab would be second), title of tabs (e.g., tab 1 : general and tab 2: risks), etc. Based upon the information of the tabs, the generation logic 710 generates the tabs (tab 1 and tab 2) of the configured master data 120(1). Essentially, the generation logic 710 generates the user interface 730(a) to illustrate the tab 1 (titled: general) and tab 2 (titled: risks) of the configured master data 120(1). Once the tabs (tab 1 and tab 2) are generated, the generation logic 710 refers to the tables 8 IOC (TABUIBB) and 810D (UIBB) (refer to FIG. 8 A) to retrieve the information related to the UIBBs of each tabs (e.g., UIBB 1 and UIBB 2 of the tab 1). The information related to UIBBs including ID of UIBB related to the tab, sequence of UIBB (e.g., UIBB 1 should be above or at the top of UIBB 2, etc), UIBB title etc. Based upon the information, the generation logic 710 generates the UIBB for the tabs (1-2). For example, the generation logic 710 generates the UIBB1 and UIBB2 for tab 1. Essentially, the generation logic 710 generates the user interface 730(b) to illustrate the UIBB of the tabs. Once the UIBBs are generated, the generation logic 710 refers the tables 810E (UIBBFLD), 81 OF (FLDSCENARIO), and 810G (FLD) (refer to FIGs. 8A-8B) to retrieve the information related to the fields of the UIBBs (e.g., fields FLD1 of the UIBB1 and FLD2 of the UIBB2, as illustrated in FIG. 7). The information like field ID, scenario, property of the field in the scenario, whether the field is customizable (customer can change the value of the field), etc., may be retrieved from the metadata 800. Based upon the information, the generation logic 710 generates the fields, e.g., FLD1 for the UIBB1 and FLD 2 for the UIBB 2, as illustrated in FIG. 7. Essentially, the generation logic 710 generates the user interface 730(c) to illustrate the fields FLD1-FLD2 of the UIBB 1 and fields of the UIBB 2 (not shown). Essentially, the generation logic 710 dynamically generates and renders the configured master data 120(1).
[0031] In one embodiment, the user can create a new or user defined master data (not shown). Typically, the master data configuration tool 110 provides an option to generate the user defined master data or to modify the predefined master data 120(1). Essentially, the master data configuration tool 110 displays an icon (e.g., 'modify', 'update', etc) to modify the predefined master data 120(1). Once the icon, e.g., modify is
selected, various components (tab, UIBBs, and fields) of the master data 120(1) may be modified or updated. Similarly, the master data configuration tool 110 displays an icon ('new', 'generate new', 'create new', etc) for generating the new (user defined) master data. Essentially, the master data configuration tool 110 provides an option to define tabs, UIBBs, and one or more fields for the new master data. The fields may be defined by either selecting one or more fields from a plurality of predefined fields (not shown) or by creating one or more new fields. A new field may be created by selecting an icon ('add new field', 'generate field', 'create field', etc) displayed on the master data configuration tool 110. Once the icon, e.g., 'create field' is selected, various information related to the field, e.g., field name, category (db, file, etc), property (hidden, display only, optional, and required), etc., may be set by the user. In one embodiment, the new field may be generated by selecting and modifying the existing field. In another embodiment, the new field (user defined field) can be associated with the existing master data 120(1).
[0032] FIG. 9 is a flowchart illustrating a method for configuring the master data 120(1) based upon the scenario 130 using the master data configuration tool 110. The master data configuration tool 110 renders the list of predefined master data 200 on the computer system 140 at step 901. The user selects the master data 120(1) to be used in the application developed by the user and the master data configuration tool 110 receives the user's selection of the master data 120(1) at step 902. The master data configuration tool 110 then displays the list of scenarios defined for the selected master data 120(1) at step 903. The master data configuration tool 110 receives the user selection of the scenario 130 from the list of scenarios at step 904. The master data configuration tool 110 configures the master data 120(1) based upon the scenario 130 selected by the user at step 905. Essentially, master data configuration tool 1 10 makes it possible to customize the master data 120(1), based upon the scenario 130.
[0033] Some embodiments of the invention may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe
implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments of the invention may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
[0034] The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term "computer readable storage medium" should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term "computer readable storage medium" should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits ("ASICs"), programmable logic devices ("PLDs") and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the invention may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the invention may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
[0035] FIG. 10 is a block diagram of an exemplary computer system 1000. The computer system 1000 includes a processor 1005 that executes software instructions or code stored on a computer readable storage medium 1055 to perform the above-illustrated methods of the invention. The computer system 1000 includes a media reader 1040 to read the instructions from the computer readable storage medium 1055 and store the
instructions in storage 1010 or in random access memory (RAM) 1015. The storage 1010 provides a large space for keeping static data where at least some instructions could be stored for later execution. The stored instructions may be further compiled to generate other representations of the instructions and dynamically stored in the RAM 1015. The processor 1005 reads instructions from the RAM 1015 and performs actions as instructed. According to one embodiment of the invention, the computer system 1000 further includes an output device 1025 (e.g., a display) to provide at least some of the results of the execution as output including, but not limited to, visual information to users and an input device 1030 to provide a user or another device with means for entering data and/or otherwise interact with the computer system 1000. Each of these output devices 1025 and input devices 1030 could be joined by one or more additional peripherals to further expand the capabilities of the computer system 1000. A network communicator 1035 may be provided to connect the computer system 1000 to a network 1050 and in turn to other devices connected to the network 1050 including other clients, servers, data stores, and interfaces, for instance. The modules of the computer system 1000 are interconnected via a bus 1045. Computer system 1000 includes a data source interface 1020 to access data source 1060. The data source 1060 can be accessed via one or more abstraction layers implemented in hardware or software. For example, the data source 1060 may be accessed by network 1050. In some embodiments the data source 1060 may be accessed via an abstraction layer, such as, a semantic layer.
[0036] A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
[0037] A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open Database Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
[0038] In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however that the invention can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details to avoid obscuring aspects of the invention.
[0039] Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments of the present invention are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the present invention. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
[0040] The above descriptions and illustrations of embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made to the invention in light of the above detailed description. Rather, the scope of the invention is to be determined by
the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
Claims
1. An article of manufacture including a computer readable storage medium to tangibly store instructions, which when executed by a computer, cause the computer to: render a list of predefined master data;
receive a user's selection of a master data from the list of predefined master data; display a list of scenarios defined for the selected master data;
receive a user's selection of a scenario from the list of scenarios; and
configure the master data based upon the selected scenario.
2. The article of manufacture of claim 1 further comprising instructions which when executed cause the computer to render the configured master data on a user interface.
3. The article of manufacture of claim 1 further comprising instructions which when executed cause the computer to provide an option to the user to perform at least one of the following:
generate one or more user defined master data;
generate one or more user defined scenarios;
modify one or more predefined master data; and
modify one or more scenarios from the list of scenarios.
4. The article of manufacture of claim 3, wherein the user defined master data is generated by defining one or more fields for the master data and wherein one or more fields are defined by selecting one or more fields from a plurality of predefined fields or by creating one or more new fields for the master data.
5. The article of manufacture of claim 3, wherein the user defined scenario is generated by setting a property of one or more fields of the master data and wherein the property may comprises one of a hidden, display only, required, and optional.
6. The article of manufacture of claim 3, wherein the user defined scenario is stored in the list of scenario defined for the master data.
7. The article of manufacture of claim 3, wherein the predefined master data is modified by adding one or more new fields to the master data or by modifying one or more predefined fields of the master data.
8. The article of manufacture of claim 3, wherein the scenario is modified by modifying a property of one or more fields related to the master data.
9. A computerized method for configuring a master data based upon a scenario, the method comprising:
rendering a list of predefined master data;
receiving a user's selection of the master data from the list of predefined master data;
displaying a list of scenarios defined for the selected master data;
receiving a user's selection of the scenario from the list of scenarios; and configuring the master data based upon the user selected scenario.
10. The method of claim 9 further comprising:
generating a user interface based upon the configured master data.
11. The method of claim 9 further comprising providing an option to the user for performing at least one of the following:
generating one or more user defined master data;
generating one or more user defined scenarios;
modifying one or more predefined master data; and
modifying one or more scenarios from the list of scenarios.
12. The method of claim 11, wherein generating the user defined master data comprises defining one or more fields of the master data and wherein defining one or more fields of the master data comprises at least one of the following:
selecting one or more fields from the plurality of predefined fields; and
creating one or more new fields for the master data.
13. The method of claim 11, wherein generating the user defined scenario comprises setting a property of one or more fields of the master data and wherein the property comprises one of characteristic selected from a group consisting of hidden, display only, required, and optional.
14. The method of claim 11, wherein modifying the predefined master data comprises at least one of the following:
adding one or more new fields to the master data; and
modifying one or more predefined fields of the master data.
15. The method of claim 11, wherein modifying the predefined scenario comprises modifying a property of one or more fields related to the master data.
16. A computer system for configuring a master data based upon a scenario, comprising:
a memory to store a program code; and
a processor communicatively coupled to the memory, the processor configured to execute the program code to:
render a list of predefined master data;
receive a user's selection of the master data from the list of predefined master data;
display a list of scenarios defined for the selected master data; receive a user's selection of the scenario from the list of scenarios; and configure the master data based upon the user selected scenario.
17. The computer system of claim 16, wherein the processor is further configured to render the configured master data on a user interface device.
18. The computer system of claim 16, wherein the processor is further configured to provide an option to the user to perform at least one of the following:
generate one or more user defined master data;
generate one or more user defined scenarios;
modify one or more predefined master data; and modify one or more scenarios from the list of scenarios.
19. The computer system of claim 18, wherein the user defined scenario is generated by setting a property of one or more fields of the master data and wherein the processor is further configured to store the user defined scenario in the list of scenarios.
20. The computer system of claim 19, wherein the processor is further configured to provide the option to the user to generate one or more user defined master data by defining one or more fields for the master data.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2010/079529 WO2012075623A1 (en) | 2010-12-07 | 2010-12-07 | Configuring master data based upon scenarios |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2010/079529 WO2012075623A1 (en) | 2010-12-07 | 2010-12-07 | Configuring master data based upon scenarios |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2012075623A1 true WO2012075623A1 (en) | 2012-06-14 |
Family
ID=46206526
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2010/079529 WO2012075623A1 (en) | 2010-12-07 | 2010-12-07 | Configuring master data based upon scenarios |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2012075623A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140095233A1 (en) * | 2012-10-01 | 2014-04-03 | Oracle International Corporation | Efficiently modeling database scenarios for later use on life data |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1369805A (en) * | 2001-02-15 | 2002-09-18 | 英业达股份有限公司 | System and method for dynamically generating table on network page |
CN1656476A (en) * | 2002-06-12 | 2005-08-17 | 甲骨文国际公司 | Methods and systems for managing styles in electronic documents |
CN101253494A (en) * | 2005-08-30 | 2008-08-27 | 微软公司 | Customizable spreadsheet table styles |
-
2010
- 2010-12-07 WO PCT/CN2010/079529 patent/WO2012075623A1/en active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1369805A (en) * | 2001-02-15 | 2002-09-18 | 英业达股份有限公司 | System and method for dynamically generating table on network page |
CN1656476A (en) * | 2002-06-12 | 2005-08-17 | 甲骨文国际公司 | Methods and systems for managing styles in electronic documents |
CN101253494A (en) * | 2005-08-30 | 2008-08-27 | 微软公司 | Customizable spreadsheet table styles |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140095233A1 (en) * | 2012-10-01 | 2014-04-03 | Oracle International Corporation | Efficiently modeling database scenarios for later use on life data |
US11449952B2 (en) * | 2012-10-01 | 2022-09-20 | Oracle International Corporation | Efficiently modeling database scenarios for later use on live data |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8555249B2 (en) | Lifecycle stable user interface adaptations | |
US8863005B2 (en) | Propagating business object extension fields from source to target | |
KR101033446B1 (en) | User interfaces for data integration systems | |
US9519701B2 (en) | Generating information models in an in-memory database system | |
US7925985B2 (en) | Methods and apparatus for process thumbnail view | |
US10372423B2 (en) | System and method for managing resources using a compositional programming model | |
EP2463790B1 (en) | Manipulation of elements and their attributes in graphical user interfaces | |
US8935218B2 (en) | Multi-client generic persistence for extension nodes | |
US8924914B2 (en) | Application creation tool toolkit | |
US20170185612A1 (en) | Dynamically designing web pages | |
US8682936B2 (en) | Inherited entity storage model | |
US10114619B2 (en) | Integrated development environment with multiple editors | |
US20080010082A1 (en) | System and method for business process management | |
US20190180337A1 (en) | Requirement-specific configuration of user interface forms | |
US20150244567A1 (en) | Unified configuration for cloud integration | |
US9361286B2 (en) | Visual tracking of report changes | |
US20140130008A1 (en) | Generating information models | |
US20140143270A1 (en) | Generating dynamic drilldown reports | |
US9904452B2 (en) | Building user specific user interface instances | |
US20130127863A1 (en) | Determining an optimal sequence of status transitions for business objects | |
US9842011B2 (en) | Delegating a status visualization task to a source application by a target application | |
US8495104B2 (en) | Database child object wizard | |
WO2009055759A2 (en) | Declarative model interpretation | |
WO2012075623A1 (en) | Configuring master data based upon scenarios | |
US20120174195A1 (en) | Function module dispatcher |
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: 10860426 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 10860426 Country of ref document: EP Kind code of ref document: A1 |