CLIAMS:WE CLAIM:

1. A system for dynamic data modeling in a software application, the system comprising:
a memory; and
a processor coupled to the memory, wherein the processor is configured to perform the steps of:
generating a set of data models, applicable to the software application, wherein the set of data models are generated in the form of a generic document format;
storing the set of data models into a model database;
generating a set of rules for each data model from the set of data models;
storing the set of rules into a rule database with a link to a corresponding data model from the set of data models;
selecting a target data model from the set of data models, wherein the target data model is to be updated;
accepting an attribute, from the target data model, to be updated;
updating the target data model with the attribute when the attribute is absent in the target data model;
updating a rule database with a set of new rules associated with the attribute when the attribute is already existing in the target data model by
identifying a set of existing rules associated with the attribute from the rule database;
updating the set of existing rules with the set of new rules associated with the attribute;
publishing the set of new rules at runtime;
updating the target data model with the attribute; and
updating the model database with the target data model.

2. The system of claim 1, wherein each data model from the set of data models is generated using the generic document format by:
generating the generic document format associated with the data model wherein the generic document format represents the data model in as a key-value pair;
updating a set of sub models using a set of standard attributes to the generic document format, wherein the set of sub models is associated with the data model; and
updating a set of attributes associated with the data model into the generic document format.

3. The system of claim 1, wherein the set of rules for each data model from the set of data models is generated by:
parsing the data model to fetch the set of attributes associated with the data model;
generating a set of rules for at least one attribute from the set of attributes based on a set of business needs specified;
updating the rule database with the set of rules;
linking the set of rules to the data model using the key-value pair; and
publishing the set of rules at runtime.

4. The system of claim 1, wherein the set of new rules are updated by:
identifying a set of change in the target data model;
publishing by the software application, an event using a unique message signature, wherein the event represents the target data model to be updated;
recognizes the incoming event based on the target data model in the unique message signature;
fetching the new rules related to the target data model;
publishing the new rules at runtime; and
communicating with the software application using the unique message signature associated with the target data model.

5. A method for dynamic data modeling in a software application, the method comprising steps of:
generating, by a processor, a set of data models, applicable to the software application, wherein the set of data models are generated in the form of a generic document format;
storing, by the processor, the set of data models into a model database;
generating, by the processor, a set of rules for each data model from the set of data models;
storing, by the processor, the set of rules into a rule database with a link to a corresponding data model from the set of data models;
selecting, by the processor, a target data model from the set of data models, wherein the target data model is to be updated;
accepting, by the processor, an attribute from the target data model, to be updated;
updating, by the processor, the target data model with the attribute when the attribute is absent in the target data model;
updating, by the processor, a rule database with a set of new rules associated with the attribute when the attribute is already existing in the target data model by
identifying a set of existing rules associated with the attribute from the rule database;
updating the set of existing rules with the set of new rules associated with the attribute;
publishing the set of new rules at runtime;
updating the target data model with the attribute; and
updating, by the processor, the model database with the target data model.

6. The method of claim 5, wherein each data model from the set of data models is generated using the generic document format by:
generating the generic document format associated with the data model wherein the generic document format represents the data model in as a key-value pair;
updating a set of sub models using a set of standard attributes to the generic document format, wherein the set of sub models is associated with the data model; and
updating a set of attributes associated with the data model into the generic document format.

7. The method of claim 5, wherein the set of rules for each data model from the set of data models is generated by:
parsing the data model to fetch the set of attributes associated with the data model;
generating a set of rules for at least one attribute from the set of attributes based on a set of business needs specified;
updating the rule database with the set of rules;
linking the set of rules to the data model using the key-value pair; and
publishing the set of rules at runtime.

8. The method of claim 5, wherein the set of new rules are updated by:
identifying a set of change in the target data model;
publishing by the software application, an event using a unique message signature, wherein the event represents the target data model to be updated;
recognizes the incoming event based on the target data model in the unique message signature;
fetching the new rules related to the target data model;
publishing the new rules at runtime; and
communicating with the software application using the unique message signature associated with the target data model.

9. A computer program product having embodied thereon a computer program for dynamic data modeling in a software application, the computer program product comprising:
a program code for generating a set of data models, applicable to the software application, wherein the set of data models are generated in the form of a generic document format;
a program code for storing the set of data models into a model database;
a program code for generating a set of rules for each data model from the set of data models;
a program code for storing the set of rules into a rule database with a link to a corresponding data model from the set of data models;
a program code for selecting a target data model from the set of data models, wherein the target data model is to be updated;
a program code for accepting an attribute, from the target data model, to be updated;
a program code for updating the target data model with the attribute when the attribute is absent in the target data model;
a program code for updating a rule database with a set of new rules associated with the attribute when the attribute is already existing in the target data model by
identifying a set of existing rules associated with the attribute from the rule database;
updating the set of existing rules with the set of new rules associated with the attribute;
publishing the set of new rules at runtime;
updating the target data model with the attribute; and
a program code for updating the model database with the target data model. ,TagSPECI:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
SYSTEM AND METHOD FOR DYNAMIC DATA MODEL CREATION AND UTILIZATION FOR RULE ORCHESTRATION

Applicant
Tata Consultancy Services Limited
A Company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India

The following specification describes the invention and the manner in which it is to be performed.
CROSS-REFERENCE TO RELATED APPLICATIONS AND PRIORITY
[001] The present application does not claim priority from any patent application.

TECHNICAL FIELD
[002] The present disclosure in general relates to data modelling. More particularly, the present disclosure relates to a system and method for dynamically generating and updating data models in multi-tier architecture.
BACKGROUND
[003] The development in information technology (IT) Infrastructure has led to a tremendous growth in e-commerce and online trading. Most of the traditional businesses are now being conducted using internet and IT infrastructure. In the current business ecosystem the need for changing the rules, governing the business policies is very frequent irrespective of whether it is Desktop/Web/Mobile Applications. For instance E-trading websites such as AmazonTM, E-BayTM, FlipkartTM, and the like are competing with each other by launching new offers and schemes every day on their websites. However, updating an application requires change in backend code as well as updating data models stored in backend database in order to reflect the changes in business policies for example new offers and discounts. Further, if the application is down for a certain amount of time while the code is being updated, it results into huge financial losses. At present, rule engines extend system functions and business functionality utilizing static data models from integrating new changes into the systems.
[004] At the backend, the static data models are embedded at compile time into the rule engine. The rules are then created and published on the static models. Integrating systems have to embed the rules created on the static data models into their systems either at compile time or by generating code in order to evaluate the rules at run time. This makes the systems very rigid and inflexible for extensibility. Addition, deletion and changes to an attribute within the data model require changes to the code base in all encompassing systems. Another significant drawback is communication message signatures with integrating systems. There could be multiple data models used in the communication between systems. Every new model addition requires changes to the producer and consumer codebase.

 
SUMMARY
[005] This summary is provided to introduce aspects related to systems and methods for dynamically generating and updating data models at runtime and the aspects are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[006] In one implementation, a method for dynamic data modelling in a software application is disclosed. Initially, a set of data models applicable to the software application are generated by a processor, wherein the set of data models are generated in the form of a generic document format. The set of data models is stored into a model database by the processor. Further, a set of rules corresponding to each data model from the set of data models is generated and stored into a rule database by the processor. In one embodiment, the rule database also stores the link between the set of rules and the corresponding data model from the set of data models. Further, a target data model to be updated is selected from the set of data models by the processor. Further, an attribute is accepted by the processor, wherein the attribute is to be updated into the target data model. In the next step, the processor updates the target data model with the attribute when the attribute is absent in the target data model. If the attribute already exists in the target data model, the processor updates the rule database with a set of new rules associated with the attribute. In order to update the set of new rules, initially a set of existing rules associated with the attribute are identified from the rule database. In the next step, the set of existing rules are updated with the set of new rules associated with the attribute. In the next step, the set of new rules are published at runtime. Further, the attribute is updated to the target data model. Once the attribute is updated, the processor updates the model database with the target data model.
[007] In one implementation, a system for dynamic data modelling in a software application is disclosed. The system comprises a processor and a memory coupled to the processor, wherein the processor is configured to generate a set of data models applicable to the software application, wherein the set of data models are generated in the form of a generic document format. The set of data models is stored into a model database by the processor. Further, the processor generates a set of rules corresponding to each data model from the set of data models and stores the set of rules into a rule database. In one embodiment, processor is also configured to store the link between the set of rules and the corresponding data model from the set of data models into the rule database. Further, a target data model to be updated is selected from the set of data models by the processor. Further, an attribute is accepted by the processor, wherein the attribute is to be updated into the target data model. Furthermore, the processor is configured to update the target data model with the attribute when the attribute is absent in the target data model. If the attribute already exists in the target data model, the processor is configured to update the rule database with a set of new rules associated with the attribute. In order to update the set of new rules, initially a set of existing rules associated with the attribute are identified from the rule database. Further, the processor is configured to update the set of existing rules with the set of new rules associated with the attribute. Once the processor updates the set of new rules, the processor is further configured to publish the set of new rules at runtime. Further, the attribute is updated to the target data model by the processor. Once the attribute is updated, the processor updates the model database with the target data model.
[008] In one implementation, a computer program product having embodied thereon a computer program for dynamic data modelling in a software application is disclosed. The computer program comprises a program code for generating a set of data models, applicable to the software application, wherein the set of data models are generated in the form of a generic document format. Further, the computer program comprises a program code for storing the set of data models into a model database and generating a set of rules for each data model from the set of data models. Further, the computer program comprises a program code for storing the set of rules into a rule database with a link to a corresponding data model from the set of data models. Further, the computer program comprises a program code for selecting a target data model from the set of data models, wherein the target data model is to be updated. Further, the computer program comprises a program code for accepting an attribute, from the target data model, to be updated. Further, the computer program comprises a program code for updating the target data model with the attribute when the attribute is absent in the target data model and a program code for updating a rule database with a set of new rules associated with the attribute when the attribute is already existing in the target data model by identifying a set of existing rules associated with the attribute from the rule database, updating the set of existing rules with the set of new rules associated with the attribute, publishing the set of new rules at runtime, and updating the target data model with the attribute. Further, the computer program comprises a program code for updating the model database with the target data model.
 
BRIEF DESCRIPTION OF DRAWINGS
[009] The detailed description is described with reference to the accompanying Figures. In the Figures, the left-most digit(s) of a reference number identifies the Figure in which the reference number first appears. The same numbers are used throughout the drawings to refer like/similar features and components.
[010] Figure 1 illustrates a network implementation of a system for dynamic data modelling is disclosed, in accordance with an embodiment of the present disclosure.
[011] Figure 2 illustrates the system for dynamic data modelling, in accordance with an embodiment of the present disclosure.
[012] Figure 3 illustrate a flowchart for dynamic data modelling in a software application, in accordance with an embodiment of the present disclosure.
[013] Figure 4 illustrates a flowchart for generating the set of data models applicable to the software application, in accordance with an embodiment of the present disclosure.
[014] Figure 5 illustrates a flowchart for generating the rules corresponding to each data model associated with the software application, in accordance with an embodiment of the present disclosure.
[015] Figure 6 illustrates a flowchart for updating attributes associated with a target data model, in accordance with an embodiment of the present disclosure.
[016] Figure 7 illustrates a flowchart for updating new rules associated with a changed attribute from the target data model, in accordance with an embodiment of the present disclosure.
DETAILED DESCRIPTION
[017] The present disclosure relates to systems and methods for dynamic data modelling in a software application.
[018] The system comprises a processor for generating a set of data models applicable to the software application, wherein the set of data models are generated in the form of a generic document format. Further, the processor generates a set of rules corresponding to each data model from the set of data models and stores the set of rules into a rule database. Further, a target data model to be updated is selected from the set of data models by the processor. Further, an attribute is accepted by the processor, wherein the attribute is to be updated into the target data model. Furthermore, the processor is configured to update the target data model with the attribute when the attribute is absent in the target data model. If the attribute already exists in the target data model, the processor is configured to update the rule database with a set of new rules associated with the attribute and then update the attribute into the target data model. Once the attribute is updated, the processor updates the model database with the target data model.
[019] While aspects of described system and method for dynamic data modelling in a software applicationareimplemented over a dedicated platform, it may be implemented in any number of different computing systems, environments, and/or configurations, the embodiment's are described in the context of the following exemplary system.
[020] Referring now to Figure1, a network implementation 100 of a system 102 for dynamic data modelling in a software application is illustrated, in accordance with an embodiment of the present disclosure. Although the present disclosure is explained by considering that the system 102 is implemented as a software program on a server, it may be understood that the system 102 may also be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, cloud, and the like. It will be understood that the system 102 may be accessed by multiple users through one or more user devices 104-1, 104-2…104-N, collectively referred to as user devices 104 hereinafter, or applications residing on the user devices 104. Examples of the user devices 104 may include, but are not limited to, a portable computer, a personal digital assistant, a hand-held device, and a workstation. The user devices 104 are communicatively coupled to the system 102 through a network 106. Further the network 106 is also enabled to connect the system with a software application 108.The system 102 is configured to maintain a set of data models and a set of rules associated with the software application 108.
[021] In one implementation, the network 106 may be a wireless network, a wired network or a combination thereof. The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network 106 may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further the network 106 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.
[022] Referring now to Figure2, the system 102 is illustrated in accordance with an embodiment of the present disclosure. In one embodiment, the system 102 may include at least one processor 202, an input/output (I/O) interface 204, and a memory 206. The at least one processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 202 is configured to fetch and execute computer-readable instructions stored in the memory 206.
[023] The I/O interface 204 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface 204 may allow the system 102 to interact with a user directly or through the user devices 104. Further, the I/O interface 204 may enable the system 102 to communicate with other computing devices, such as web servers and external data servers (not shown). The I/O interface 204 may facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The I/O interface 204 may include one or more ports for connecting a number of devices to one another or to another server.
[024] The memory 206 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 206 may include modules 208 and system data 230.
[025] The modules 208 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. In one implementation, the modules 208 may include a reception module 210, a displaying module 212, a data model generation module 214, a data model manager module 216, a rule orchestrator module 218, a rule mapping module 220, a rule publisher module 222 and other modules 224. The other modules 224 may include programs or coded instructions that supplement applications and functions of the system 102.
[026] The system data 230, amongst other things, serves as a repository for storing data processed, received, and generated by one or more of the modules 208. The system data 230 may also include a system database 232 and other data 234. The other data 234 may include data generated as a result of the execution of one or more modules in the other modules 224. The system data 230 is further configured to maintain a model database 226 and a rule database 228. The model database 226 is configured to store a set of data models applicable to the software application 108. Further, the rule data base is configured to store a set of rules applicable to the software application 108.
[027] In one implementation, the multiple users may use the client devices 104 to access the system 102 via the I/O interface 204.The system 102 may employ the reception module 210 to accept inputs from the user devices 104. Further, the system enables the data model generation module 214 to enable users to generate the set of data models applicable to the software application 108, wherein the set of data models are generated in the form of a generic document format. Once the set of data models is generated, the system 102 stores the set of data models into the model data base 226.
[028] In one embodiment, the rule orchestrator module 218 is configured to generate a set of rules applicable to the software application 108. Each of the rules from the set of rules is linked to the corresponding data model from the set of data models and stored into the rule database 228.
[029] Once the rules are generated the user may propose changes to the software application 108using a target data model from the software application 108. These changes may be in the form of adding new attributes or updating existing attributes associated with a target data model. Once the target data model is updated in the model database 226, the system 102 accepts or identifies rules that are applicable to changed attributes of the target data model.
[030] Further, the system 102 updates the rules and the target data model to the rule database 228 and model database 226 based on the whether the target data model already existed in the set of data models. Further, the complete flow of the system 102 is explained with respect to the flowchart of figure 3.
[031] Referring now to Figure 3, a flowchart for dynamic data modelling for the software application 108 is disclosed.
[032] At block 302, the system 102 enables the data model generation module 214 to generate the set of data models applicable to the software application 108. Once the set of data models is generated, the system 102 stores the set of data models into the model data base 226. The process of generating the data models is further explained with respect to figure 4.
[033] At block 304, the rule orchestrator module 218 of the system 102 is configured to generate a set of rules applicable to the set of data models. Each of the rules from the set of rules is linked to the corresponding data model from the set of data models and stored into the rule database 228. The process of generating the set of rules is further elaborated with respect to the flowchart of figure 5.
[034] At block 306, the user may propose changes to the software application 108 in the form of adding new attribute of changing the existing attributes in a target data model associated with the software application 108. These changes are reflected only when the target data model from the set of data models is updated with the new attribute or updated attribute. Once new/ updated attribute is embedded into the target data model, the system 102 updates the existing rules or accepts new rules that are applicable to the new/updated attribute from the target data model. The process of updating the target data model is elaborated with respect to the flowchart of figure 6.
[035] At block 308, the system 102 updates the existing rules or adds new rules corresponding to the changed attribute into the rule database 228 based on the whether the changed attribute already existed in the target data model or is a newly added attribute. The process of dynamically updating the rule database 228 is elaborated in figure 7.
[036] Referring now to Figure 4, the detailed working of block 302 for generating the set of data models applicable to the software application 108is disclosed. The process of dynamic data model creation involves assembling attributes and associated data types into a generic document format.
[037] At step 402, the system 102 is configured to accept a data model name for the data model using the reception module 210.
[038] At step 404, the system 102 displays a set of available attributes names over the user interface 204. The available attributes are linked with different data structures such as integers, variables, string, and the like. Further, the system 102 also enables the users to generate new attributes with different data structures for embedding into the data model.
[039] At step 406, the system 102 enables the user to select a set of attributes for the data model from the available attributes and/or newly generated attributes.
[040] At step 408, a data model is generated based on the data model name and the set of attributes selected by the user. The data model generation module 214 is responsible to import and/or create any number of attributes to produce/transform the data model into a generic data model document. In one embodiment, the data model generation module 214 can choose from variety of standalone models or standard data types as defined in the system 102. Such standard data types include other data sub models that are already created and stored in the model database 226 of the system 102. Further, the data model generation module 214is configured to create a new data type using an assembly and make it available in future as generation of the data models. In one embodiment, the assembled data models are generated by the data model generation module 214in a generic document format.
[041] At step 410, once the data model is created, the data model is stored in the model database 226 in a generic document format. In a similar manner, all the data models associated with the software application 108 are generated and stored in the model database 226.
[042] Referring now to Figure 5, the detailed working of block 304 for generating the rules corresponding to each data model from the model database 226 is disclosed.
[043] At step 502, the set of data models associated with the software application 108 are retrieved from the model database 226.
[044] At step 504, a data model from the set of data models is selected for generating rules corresponding to the attributes present in the data model.
[045] At step 506, the system 102 displays the attributes associated with the data model on the user interface 204.
[046] At step 508, based on business logic specified by the user, the system 102 enablesgenerating rules corresponding to each attribute present in the data model. Rules are created on these attributes based on business need specified by the user. These rules can define conditional logic to build decision trees. The rules once defined are stored into the rule database 228 with a link to the data model they belong to. In a similar manner, rules associated with each of the data model are generated and stored in the rule database 228.
[047] At step 510, the rules are published at runtime. The rules are published in order to enable inter system communication.
[048] At step 512, once the rules are published, the unique message signature associated with the data model is used for communication between the system 102 and the software application 108. The software application 108 records this information for future use and updates the corresponding data model present at the software application 108. The process for updating the data model associated with the software application is illustrated with respect to the flowchart of figure 6.
[049] Referring now to Figure 6, the detailed working of block 306 for updating attributes associated with a target data model into the model data base 226 is disclosed. As part of the business process in the software application 108, if an attribute is changed i.e. if there are any modifications proposed to the attribute associate with the target data model in the software application 108, the attribute needs to flow into the rule mapping module 220 to realize the changes throughout the system 102.
[050] For this purpose, at step 602, the system 102 identifies changes in a target data model present in the software application 108 when this target data model flows into the system 102 from the software application 108.
[051] At step 604, the system 102 compares the target data model from software application 108 with the corresponding target data module that is stored in the model database 226. This step is performed in order to identify a changed attribute from the target data model associated with software application 108.
[052] At step 606, the system 102 analysis the changed attribute to identify whether the attribute is a new attribute or an existing attribute that has undergone changes. If the changed attribute is identified as the new attribute, the system 102 is configured to add this attribute into the target data mode that is stored in the model database 226.
[053] At step 608, if the changed attribute is identified as existing attribute that has undergone changes, the system 102 is configured to replace the existing attribute with the changed attribute in the target data mode that is stored in the model database 226.
[054] Once the target data model is updated, the system 102 updates/adds the rule database 228 with the new rules associated with the changed attribute from the target data model. The process for updating/adding new rules associated with the changed attribute into the rule database 228 is further explained with respect to the flowchart of figure 7.
[055] Referring now to Figure 7, the detailed working of block 308 for updating the rule database 228 with the new rules associated with the changed attribute is illustrated.
[056] At step 702, if the changed attribute is a newly added attribute, the system accepts new rules that are associated with the changed attribute and appends the new rules to the rule database 228.The rule mapping module 220 dynamically recognizes the modification in rule associate with the new attribute for rule evaluation at runtime.
[057] At step 704, if the changed attribute is an existing attribute that has undergone change, the system 102 identifies the rules that are applicable to this existing attribute from the rule database 228. Further, the system 102 updates the rules that are applicable to the existing attribute in order to reflect the changes in the existing attribute. For example if the name of the existing attribute is change from “Item_ID” to “Item_No” then the system 102 updates all the rules applicable to the attribute “Item_ID” to replace the attribute name from “Item_ID” to “Item_No.” The new changes in the rules are immediately available to the rule mapping module 220.
[058] At step 706, once the new rules are updated into the rule database 228, the system 102 publishes the new rules at runtime associated with the target data model.
[059] At step 708, the system 102 communicates with the software application 108 using the unique message signature. As a result, when a request for the target data model is received from the software application 108, the change in the state of the attributes associate with the target data model is immediately reflected by the system 102 with the unique signature and the new rules are recognized with immediate effect.

WORKING EXAMPLE

[060] In an embodiment, the process of generating a dynamic data model “Order” and maintaining the data model into the model database 226 is illustrated as below
[061] Phase1: (For generating and storing the data models)
[062] Consider the “Order” data model with following attributes: Order {Customer Name, Address (Street 1, Street 2, Zip, Pin, Country), Region, Date time, Item (item, quantity, price), currency} that is to be stored in the model database 226. The Order data model has several sub models embedded. The data model generation module 214is configured to first create the sub objects i.e. “Address” with attributes Street1, Street 2, Zip, Pin and Country. Subsequently data model generation module 214is configured to generate the Item object with attributes item, quantity and price. The objects Address and Item act as two sub objects available in the system 102. Now, the “Order” data model is created by embedding the sub objects & the other attributes {Customer Name, Region, Date, time and currency}into a generic document format, which represents the object as key-value pairs. The generic document format provides future extensibility and loose coupling.
[063] The generic model document format of the “Order” data model is outlined below:
Order
{
"customerName": "",
"region": "",
"currency": "",
"address": {
"street1": "",
"street2": "",
"zip": "",
"pin": "",
"country": ""
},
"orderItem": {
"item": "",
"quantity": 0,
"price": 0.0
}
}
[064] The “Order” dynamic model is available at runtime without any compilation/deployment that can be used by rule mapping module 220, software application108 or model generation module 214 for further processing.
[065] Phase2: (For generating and storing rules associated with the data models)
[066] Once the “Order” data model is generated, the rule orchestrator module 218now has the Order model to create dynamic rules at runtime. The sub models and attributes from the Order model are used by the rule orchestrator module 218 to generate the corresponding rules. For instance, consider the business rule for the season sale to offer discount of 1%, if quantity purchased is more than 5, the rule orchestrator module 218 is configured to create the dynamic rule as given by the condition:
If Order.orderItem.quantity> 5 then
Order.orderItem.price = Order.orderItem.price - (Order.orderItem.price * .01)
[067] This rule is then stored in the rule database 228. Further a link corresponding to the data model i.e. Order.OrderItem is also maintained with the rule in the rule database 228.Further, the rule orchestrator module 218 publishes the dynamic generated rule to be made available to system 102 at runtime. Further, is used for communication between the system 102 and the software application. The unique message signature in this case is given by:
{Model: Order :
{
"customerName": "",
"region": "",
"currency": "",
"address": {
"street1": "",
"street2": "",
"zip": "",
"pin": "",
"country": ""
},
"orderItem": {
"item": "",
"quantity": 0,
"price": 0.0
}
}
}
[068] Due to the unique message signature, there are no changes required to the original external system object. A wrapper around the external system object containing Model identifier needs to be added, to publish the “Order” event to the rule mapping module220 at runtime. For the communication with rule mapping module 220, the system 102 uses the unique message signature by wrapping the original object with the model identifier in order toensures that the object structure of the system 102 will not need any change for inter-system communication. The unique message signature is given by {Model:< Model Name > :Object : { id:, name: }}. The unique message signature in case of the “Order” data model is given by:
{Model: Order :
{
"customerName": "",
"region": "",
"currency": "",
"address": {
"street1": "",
"street2": "",
"zip": "",
"pin": "",
"country": ""
},
"orderItem": {
"item": "",
"quantity": 0,
"price": 0.0
}
}
}
[069] Once the system 102 publishes the Order model to the rule mapping module 220, the rule mapping module 220 recognizes the incoming event based on the data model in the unique message signature. The rule database 228 is queried to fetch rules related to Order model. The attributes on which the existing rules are defined are compared against the attributes associated with the incoming Order model. Further, a quantity is recognized as the condition decision maker. The value in the Order quantity object is replaced in the rule template and condition evaluated. If the condition is met i.e. the quantity in the orderItem is > 5 then the configured result is published back to the system 102.There could be multiple rules defined on the object, which are executed in a single event.
[070] Phase3: (For Updating the data model and rules associated therewith)
[071] Further, in order to update the Order data model, considering that an erroneous entry was made for one of the attributes in the Order model. For instance if the quantity attribute in Order.orderItem is actually represented as qty in the software application 108, the system 102 enables dynamically updating the order model. Since the rule associated with orderItemis already created with quantity and published, the order model and the associated rules have to be edited to reflect the new name for quantity. For this purpose, the data model generation module 214 identifies the Order model is first looked up. In the edit mode the attribute name under the sub model orderItem is changed to the new value “qty” in the sub model. On confirmation, a check is run against the rule database 228 to look for impact on the rules. In this case the attribute “quantity” is part of one of already existing rules, which is identified by the system 102. On continuation of the model edit, the Order model and its sub object representation is now updated in the model database 226 as follows:
Order
{
"customerName": "",
"region": "",
"currency": "",
"address": {
"street1": "",
"street2": "",
"zip": "",
"pin": "",
"country": ""
},
"orderItem": {
"item": "",
"qty": 0,
"price": 0.0
}
}
The rule database 228 is also updated to reflect the changes in orderItem quantity attribute.
If Order.orderItem.qty> 5 then
Order.orderItem.price = Order.orderItem.price - (Order.orderItem.price * .01)
[072] The updated changes are reflected immediately at runtime. The rule mapping module 220 starts recognizing the changed incoming attributes associated with the Order model.
[073] In one embodiment, if a new attribute “promoCode” is to be introduced dynamically into the Order model. Then a new rule has to be added based on the value in the promoCode attribute. For this purpose, first the new attribute has to be included in the Order model as described in the previous phase. Further, the existing Order object is looked up similar to the edit flow by the model generation module 214. Since “promoCode” is a new attribute, there is no impact on existing rules. Hence the rules impact check is skipped for the new attribute addition.
[074] The new attribute “promoCode” and its data type is configured in the model generation module 214 and the changes are stored in the model database 226. After the change the Order model is changed as shown below:
Order
{
"customerName": "",
"region": "",
"currency": "",
"promoCode":"",
"address": {
"street1": "",
"street2": "",
"zip": "",
"pin": "",
"country": ""
},
"orderItem": {
"item": "",
"qty": 0,
"price": 0.0
}
}
[075] The “promoCode” attribute is now part of the Order model. In the Rule Orchestrator module 218, the change in the Order model is immediately reflected. The “promoCode” can be used in the condition builder. For promoCode – New Offer, if a 5% discount has to be configured then the rule mapping module 220 is use to generate the new rules as shown below
If Order.promoCode = ‘New Offer’ then
Order.orderItem.price = Order.orderItem.price - (Order.orderItem.price * .05)
[076] The new rule is saved to the rule database 228. The rule engine recognizes the “promoCode” attribute in the incoming objects with the unique message signature containing the original object from the system 102. This enables a seamless workflow of models and rules with system 102 that is completely dynamic.
[077] Although implementations of system and method for dynamically generating and updating data models, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described herein. However, the specific features and methods are disclosed as examples of implementations for displaying/presenting the data in multiple levels on the user interface.