FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See Section 10 and Rule 13)
Title of invention:
A SYSTEM AND METHOD FOR MODELING A METADATA-DRIVEN SCHEMA DEFINITION FOR A PLATFORM-AS-A-SERVICE SOFTWARE
Applicant:
ENTRIB Technologies A Partnership firm registered under The Partnership Act, 1932
Having address:
Concord Proxima, Survey # 85-A, Bldg C-202,
Baner, Pune411045,
Maharashtra, India
The following specification describes the invention and the manner in which it is to be performed.

FIELD OF THE INVENTION
The present invention relates to the field of data structure management for a schema-less unstructured database. More particularly, the invention relates to the field of defining a metadata-driven schema for data records of assorted data formats stored in a schema-less unstructured database and performing CRUD operations on these data records based on metadata association.
BACKGROUND OF THE INVENTION
Platform-as-a-Service (PaaS) software system acts as a centralized platform facilitating software development and management of several applications built using software development. The PaaS enables facilitation of various Software Development Kits (SDKs), Application Programming Interfaces (APIs), libraries and tools by using which the software development fraternity can develop plurality of web-based applications. These web-based applications are then developed by plurality of customers for their day-to-day use.
Generally, the web-based applications developed and managed through the PaaS software system are built for different purposes and objectives. Each application is developed with specific customer requirements and hence the underlying PaaS software system is typically application agnostic in nature. The nature of data formats, data types and the algorithms executed related to different applications can be different. Further, there may involve several intermediate data processing steps such as extracting, transforming and loading of data from source device to destination device. Thus, it is critical to understand the nature and type of data relative to different web-based applications so that desired manipulative operations can be done on the relevant data.

In general, a database storing datasets for varied web-based applications should be a data fabric that can support data of assorted formats. This is because, the nature and type of data structure of datasets belonging to different applications is different. In a typical application where data gets stored in the Relational Database Management System (RDBMS), the data takes a structured format and gets arranged in for of tables with columns and rows. The structured database though enables structurally arranging data of assorted formats, however, in case of building several disparate web-based applications, several such data-structures need to be designed and maintained. Hence, several such structured databases may therefore be required to manage multitudes of disparate application data schemas. However, this may create an unnecessary increase in the resources and may cause inadequate burden on the machines processing the database management and application services processing. This is exactly the gap that a PaaS system tries to fill by using a single unstructured database capable of storing data sets of different data formats meant for different applications.
Unlike structured databases, unstructured databases are configured for storing of data of different formats and data types and can store data from disparate customer applications that can be built using the PaaS software system. This is the primary reason why the unstructured database is utilized for data storage. However, since these kinds of databases are unstructured and schema-less, the technical problems of:
• designing an application-specific data model,
• facilitating quick access to the datasets, and
• performing desired manipulative operations on the datasets for manipulation of application-specific requirements such as creating, accessing/reading, deleting, updating and reporting of data records, in the unstructured database needs to be solved.

Typical CRUD (create, read, update, delete) operations are generally performed on the databases in order to manipulate the data records in the databases. More particularly, create operation enables creating a new record in the database, read operation enables accessing/reading the data record stored in the database, update operation facilitates in updating the record in the database while delete operation enables deleting the record in the database. Considering the PaaS software system being application agnostic, the subscribers subscribed to these applications may at any point of time requests for execution of any one of the CRUD operations on the backend database managing the desired application. In such scenarios, since database is unstructured and schema-less, it gives rise to technical problem of quickly locating the intended dataset on which the CRUD operations is to be performed. Again, it is very difficult to build a separate data-schema for each of these applications as it may lead in wastage of time, resources and cost.
Thus, in view of the above, there is a need in the art to develop a software architecture that enables quickly building disparate customer applications by means of a data model that allows data to be manipulated through variety of operations such as Create, Read, Update and Delete (CRUD). More particularly, there is a need for a system and method that enables to model an application-specific metadata driven schema that facilitates building a data model for the application-specific requirements and further allows data to be manipulated through variety of operations such as Create, Read, Update and Delete (CRUD).
OBJECTS OF THE INVENTION
The primary object of a present invention is to enable a system and method for modeling a metadata-driven schema definition for a Platform-as-a-Service (Paas) software architecture facilitating disparate applications development.

Another object of the invention is to enable a system and method for modeling a schema with a help of metadata parameters such as elements and data-fields, wherein each element comprises of one or more data fields.
Still another object of the invention is to enable a system and method for correlating the metadata with the documents in the datastore and to perform the CRUD operations on the correlated documents using XML-based APIs.
SUMMARY OF THE INVENTION:
Before the present systems and methods, enablement are described, it is to be understood that this application is not limited to the particular apparatus, systems, and methodologies described herein, as there can be multiple possible embodiments which are not expressly illustrated in the present disclosures. It is also to be understood that the terminology used in the description is for the purpose of describing the particular versions or embodiments only, and is not intended to limit the scope of the present application.
In one embodiment, the present invention discloses a system and method for modeling a metadata driven schema definition for Platform-As-a-Service (PaaS) software facilitating development of plurality of disparate web-based applications. The system of the present invention comprises a Graphical User Interface (GUI) layer that is adapted for modeling a metadata driven schema definition for plurality of web-based applications facilitated by the PaaS software. In this embodiment, the metadata-driven schema is defined using a set of metadata elements and data-fields having one-to-many relationship. That is each element comprises of one or more data-fields. The metadata-driven schema defined is then persisted in a structured database such as SQL database.

In one embodiment, the system of the present invention further comprises of an Application Programming Interface (API) layer hosting plurality of API modules configured for performing various manipulative operations such as creating, deleting, updating, reading and reporting on plurality of documents stored in an unstructured, schema-less datastore such as NoSQL database. In this embodiment, the present invention is adapted to associate the metadata defined with the documents in the NoSQL database by passing the required element identifier and the data-fields to be manipulated in the XML-based API that retrieves a particular document to be manipulated matching with the element identifier passed and then performing either one of the create, read, update, delete and report operations on the data-fields identified in the documents matching with the passed data-fields.
BRIEF DESCRIPTION OF DRAWINGS
The foregoing summary, as well as the following detailed description of embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the present document example constructions of the invention; however, the invention is not limited to the specific methods and apparatus disclosed in the document and the drawings:
Figure 1 is a system diagram illustrating the various modules configured for defining a metadata-driven schema and enabling CRUD operations on the data associated with the defined schema according to an embodiment of the invention.
Figure 2 is a flow diagram illustrating different steps implemented for modeling a metadata driven schema in accordance with an embodiment of the invention.

DETAILED DESCRIPTION
Referring to figure 1 is system diagram illustrating the various system components configured collectively for modeling an application-specific data model and enabling various manipulative operations on the data store using the modeled data model in an embodiment of the present invention.
As illustrated in figure 1, the system (100) comprises of an application processing server (101) electronically coupled to a schema-less datastore (103) and a structured database (109). The application processing server (101) further comprises a Graphical User Interface (GUI) layer (105) and an Application Programming Interface (API) layer (107) configured for processing of one or more tasks as directed by the application processing server. In one embodiment, the application processing server (101) may be connected over a communication network with plurality communication devices configured for processing one or more dedicated tasks. In another embodiment, the application processing server (101) may act as a standalone computing device configured to instruct the GUI layer (105) and the (API) layer (107) to perform the desired tasks of designing the data model for disparate web-based applications and allow manipulative operations such as CRUD operations on the datasets stored in the schema-less datastore (103).
In an embodiment, the application processing server (101) is a computing machine that may comprise a server computer, a client user computer, a personal computer (PC), a tablet PC, a laptop computer, a desktop computer, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. The machine may include an embedded processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU, or both), a memory

which communicate with each other via a bus. The memory stores programmed instructions that when executed by the embedded processor in the application processing server (101) configures each of the system components including the schema-less datastore (103), the GUI layer (105), the API layer (109) to implement the methodology of modeling metadata driven schema definition for the data in the datastore in order to enable fast and easy desired manipulative CRUD operation on the data in the datastore. Further, while a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies as discussed herein.
In one embodiment, the schema-less datastore (103) as illustrated in figure 1 is an unstructured, schema-less and enables storage of data of any data format and data type. The schema-less datastore (103) holds a key repository of information that assists in development of several web-based applications by means of a web-based platform facilitating application developments with the help of data-reusability. Since, the type of applications developed are disparate in nature, the schema-less datastore (103) therefore acts as a mechanism that supports assorted data formats, varied application schemas and hence is not of a particular schema type. In an exemplary embodiment, the schema-less datastore (103) as illustrated in figure 1 can be a NoSQL database such as which is schema-less and enables storage of varied data formats and data types required for application developments and thereby data management.
In one embodiment, the schema-less datastore (103) is configured for abstracting software development requirements for building several web-based applications using platform-as-a-service (PaaS) deployment platforms. The schema-less datastore (103) is typically a document-oriented database system that is adapted to hold

datasets of different data type and assorted formats relative to several web-based applications to be built and deployed on the subscriber terminals subscribing the dedicated platform-as-a-service (PaaS) application. In one embodiment, the embedded processor in the application processing server (101) is configured to generate an application specific data model in the Structured Database (109) in response to requirements abstracted for the specific application to be designed and managed using the GUI layer (105). The GUI layer (105) is adapted to receive the abstraction details for designing a model from the user and a data model is developed corresponding to datasets stored in the schema-less datastore (103) which acts as a schema-less document-oriented NoSQL database.
In one embodiment, the datastore (103) is typically a schema-less document-oriented NoSQL database system that holds a set of dataset collections/tables. Each data collection or data table comprises of a set of documents. Each document in the collections/tables is a set of data fields, wherein each field is represented as a key-value pair. In one embodiment of the invention, the data type of the key field is a String and it refers to a name of particular document or other fields in the document. Further, in this embodiment, the value for each of the key field can be a selected from a group consisting of string, integer, long, double, date, binary, a document itself and an array of values etc. The collections or tables in the schema-less datastore (103) can have documents that are dynamically typed and hence each document can have a different structure and therefore act as unstructured collections or tables. The datasets of different data types and assorted data formats relative to different disparate applications are arranged randomly with no schema-definition attached to these datasets.
In one embodiment, the application processing server (101) enables to model a metadata-driven schema definition for each of the dataset stored in the unstructured,

schema-less datastore (103) as shown in figure 1. The application processing server (101) is configured for abstracting metadata model requirements to be designed from the GUI layer (105). The GUI layer (105) abstracts these requirements as per the web-based applications to be developed by means of PaaS platforms. Since, the applications developed are disparate in nature, the metadata requirements for modeling a schema are disparate and are facilitated by the application processing server (101). In one embodiment, the application- specific metadata schema is persisted in the structured database (109) as shown in figure 1. In an exemplary embodiment, said structured database (109) can be a Structured Query Language (SQL) database storing plurality of data records in a table comprising rows and columns, wherein each record is stored at the intersection of each row and column.
Referring to figure 1. the metadata driven schema definition for various disparate applications are modeled using metadata parameters including plurality of metadata elements and plurality of data-fields. In one embodiment, each metadata element represents a collection of one or more data-fields. Therefore, there exists a one-to-many relationship between the metadata elements and the data-fields in the defined schema. The metadata elements and the data-fields are defined by multiple attributes. More specifically, each metadata element in an embodiment is defined with attributes including an element identifier (ID), an element name, an element description or combinations thereof. Similarly, each data-field in each of the metadata element is defined with multiple attributes including field identifier (ID), field name, field description, field data type and identifier (ID) of the corresponding elements to which said data field belongs. In an embodiment, the data type of the data-fields includes boolean, integer, long, float, string, date, image, timestamp, time duration, Base64, audio, video or combinations thereof. Figure 2 is a flow diagram illustrating process flow of defining an application-specific metadata schema using the metadata parameters according to an embodiment of the present invention.

Referring to figure 2, as illustrated, at step (201), one more metadata elements for at least one web-based application is defined. At step (203), one or more data-fields corresponding to defined metadata elements are defined. Next, at step (205), the data type for each of the defined data-fields. Further, at step (207), it is checked whether any additional data-fields are required to be defined based on the inputs from the GUI layer (105). If any additional data-field is to be defined, then steps (203, 205) are re-iterated to include more data-fields for the corresponding metadata element. If no additional data-field is required, the application processing server then proceeds to execute step (209). At step (209), the defined metadata elements and the data-fields are persisted in the structured database (109). At step (211), as shown in figure 2, it is checked whether any additional metadata elements need to be defined. If any additional metadata element is to be defined, then steps 201 to 209 are re-iterated to define additional metadata elements which is persisted in the in the structured database (109). The underlying documents/datasets within the web-based applications get stored in the document oriented schema-less datastore (103).
In an exemplary embodiment, consider an example of modeling a metadata driven schema for two different applications: meter reading app and site inspection app. For these two completely different apps, corresponding datasets in the datastore are of completely different formats. The application processing server (101) enables to define schema on top of the same schema-less datastore (103) holding their data records in the following manner:
According to the exemplary embodiment of the present invention, the meter reading app is configured to capture the meter reading of each apartment of a society located in a particular region depicting the electricity bill for that particular apartment. In this exemplary embodiment, the meter readings captured for all the apartments are

collated on the back-end data service hosted by the PaaS platform facilitating the meter app development and the meter reading data management thereof. In the exemplary embodiment, the data model generated for the meter reading by means of received inputs from the GUI layer (105) is illustrated in the table 1 as below:

Data field Data Type
Name String
Address String
Code String
Wing String
Rate Float
Table 1: Data fields and their data type for the Element "Societies"
In this exemplary embodiment, the application processing server (101) is adapted to create metadata for the different data-fields and the metadata element "Societies" as listed in the table 1. The metadata is created in the form of tables which gets persisted in the structured database (109). Following tables illustrate the metadata created corresponding to the element "Societies" and the data-fields defined thereof:
In this exemplary embodiment, the "Society" element table will contain following data row for Societies data:

ID Name Description
1 "Society" "Society that is using MeterVue"
Table 2: Metadata table for "Societies" Element
In this exemplary embodiment, data-field table will contain following data row for data-fields in the "Societies" Element:

ID Name Description Data type Element ID
I "Name" "Name of the society" String 1
2 "Address" "Society Address" String 1
3 "Code" "Society Code" String 1
4 "Wing" "Wing" String 1
5 "Rate" "Rate
applicable to this society" Float ]
Table 3: Metadata table for data-fields corresponding to "Societies" Element
In an exemplary embodiment, the application processing server (101) creates a document for the "Societies" elements and its corresponding data-fields as defined in the form of metadata driven schema in the unstructured, schema-less datastore (103). The format of the created document in the datastore representing Societies data for the meter-reading app in an exemplary embodiment is as below:
{
"ElementName": "Societies",
"Name": "Concord Proxima",
"Address": "Survey # 85-A, Baner Road, Baner, Pune, MH",
"Code": "ABCOMM",
"Wing": "C",
"Rate": 340.45
}

In this exemplary embodiment, the sample document created in the datastore corresponding to defined metadata driven schema is in JavaScript Object Notation (JSON) format. The entire process of modeling of data model including schema definition for element and data-field and creation of document sample for the application meter-reading app is controlled through the application processing server (101) by abstracting the application-specific requirements by means of GUI layer (105) as shown in figure 1.
Similarly, a distinct model representing a metadata driven schema and a sample document can be defined for other elements for the meter-reading application as per the abstracted requirements. For example, in this exemplary embodiment, consider a "customer" element describing the customers subscribed with the meter reading application. The details corresponding to the customers are captured by defining multiple data-fields for the customer acting as an element which is represented in the table 4 as below:

Data Field Data Type
Name String
SocietyName String
CRNumber Long
FlatN umber Integer
Address String
PhoneNumber Long
MeterReading Float
MeterReadingDate Date
PreviousBalance Float
BillNumber Long

Table 4: Data fields and their data type for the element "Customers"
In this exemplary embodiment, for the "customers" element and the defined data-fields as illustrated in table 4, tables 5 and 6 collectively represents the metadata created in the SQL database (109) corresponding to the element "customers". The element "customers" table persisted in the SQL database contains following data row depicting customer data as illustrated in table 5 as below:

ID Name Description
2 "Customer" "Customer who is using Piped-Gas"
Table 5: Metadata table for "customer" Element
Further, the data-field metadata table created in the SQL database corresponding to the element "Customers" is illustrated in table 6 as below:

ID Name Description Data type Element ID
6 "Name" "Customer name"' String 2
7 "SocietyName" "Name of the Society where customer is living" String 2
8 "CRNumber" "CRN" Long 2
9 "FiatNumber" "FiatNumber" Integer 2
10 "Address" "Customer address" String 2

11
"PhoneN umber" "Contact number Long 2
12 "MeterReading" "Previous
Meter
Reading" Float 2
13 "Date when 2
"MeterReadingDate" meter reading was taken" Date
'14 "PreviousBalance" "Previous balance if any" Float 2
15 "BillNumber" "Generated bill number" Long 2
Table 6: Metadata table for data-fields corresponding to Element "customers"
In an exemplary embodiment, the application processing server (101) creates a document for the "customers" elements and its corresponding data-fields as defined in the form of metadata driven schema in the unstructured, schema-less datastore (103). The document created in the datastore representing customer data in JSON format for the meter-reading app is as below:
{
"ElementName": "Customers",
"Name": "John Doe",
"SocietyName": "Concord Proxima".
"CRNumber": 1234567890,
"Flat": 202,
"Address": "Survey # 85-A, Building C, Baner Road, Baner, Pune, MH",
"PhoneNumber: 2027219150,

"MeterReading": 123.67,
"MeterReadingDate": new ISODate ("2012-03-30TI4:26:06.203Z"),
"PreviousBalance": 23.50,
"BillNumber": 1234567890
}
Another example of web-based application according to an exemplary embodiment of the invention for which metadata schema can be modeled is a "Site-Inspection" application. The "Site-Inspection" application (app) is configured to allow enterprise users/subscribers to capture images (using their smartphones) of any site or location that needs a visual inspection. The app after capturing of images then uploads the captured images to a cloud based server and makes it available to other enterprise users based on the various privileged access levels. In this exemplary embodiment, the data model generated for the "Site-Inspection" consist of "site-image" as an element with one or more data fields as illustrated in table 7 appended below:

Data-Field Data Type
Sitelmage Image
Tags String
Description String
Latitude Float
Longitude Float
Table 7: Data fields and their data type for the element "site-image"
In this exemplary embodiment for the "site-image" element and the defined data-fields as illustrated in table 7, a metadata is created in the SQL database (109)". The

element "site-image" that is persisted in the SQL database contains following data row depicting captured image data as illustrated in table 8 as below:

ID Name Description
3 "Sitelmage" "Site inspection"
Further, the data-field metadata table created in the SQL database corresponding to the element "site-image" is illustrated in table 9 as below:

ID Name Description Data type Element ID
16 Sitelmage "Image taken" Image 3
17 Tags "Tag string" String 3
18 Description "Image description" String 3
19 Latitude "Latitude or Parllels" Float 3
20 Longitude "Longitude or meridians" Float i j
In an exemplary embodiment, the application processing server (101) creates a document for the "site-image" elements and its corresponding data-fields as defined in the form of metadata driven schema in the unstructured, schema-less datastore (103). The document created in the datastore representing site-image data in JSON format for the Site-Inspection app is as below:
{
"ElemenfName": "Sitelmage",
"Sitelmage": ,

"Tags": "Green",
"Description": "This is a nice picture", "Latitude": 18.3528631, "Longitude": 73.8526258
}
Thus, the present invention enables to store data documents having completely distinct data structure in the same underlying NoSQL database system (datastore) for managing of two different applications namely "Meter-reading" and "Site-Inspection" apps in according to exemplary embodiments. Similarly, for other apps facilitated by the platform as a service to the subscribers, different data models can be designed, sample documents can be created in the same schema-less datastore (103) and a distinct metadata driven schema for each data model can be defined and persisted in the SQL database (109).
In one embodiment, since for each web-based applications, metadata driven schema is defined, it is required to correlate the schemas persisted in the SQL database (109) for each document created in the datastore (103) as shown in figure 1 so that desired manipulative operations can be performed on the documents specific to a particular application. Such manipulative operations are generally 'create', 'read', 'update' and 'delete' operations, and are also collectively known as CRUD operations. The application processing sever (101) facilitates these manipulative operations by means of defining an Extensible Markup Language (XML) based API for each operation using the APT layer (107). In this embodiment, the application processing server in response to instructions received from the memory directs the API layer (107) to configure at least one of the create API module, the read API module, the update API module, the delete API module and the report API module to execute the

manipulative operations of creating, reading, updating, deleting and reporting respectively on the documents stored in the schema-less datastore (103).
In one embodiment, the linking or correlation of the metadata driven schema defined for each document stored in the schema-less datastore relative to disparate applications is enabled by inserting one or more data-fields in the document while creating each document in the schema-less datastore (103) to uniquely identify each document for distinct application use and processing. In one embodiment, for example, each document created in the datastore (103) is associated with the element identifier (ID) that defines the metadata driven schema. For example, by referring to tables 2 and 5, the "Society" element with description "Society that is using MeterVue" is having element ID as 1 and the "Customer' element with description "Customer who is using Piped-Gas" is having element ID as 2. These IDs are passed into XML-based create API to associate the schema defined in the structured database (109) for corresponding document in the schema-less datastore (103).
In one embodiment, in addition to the element identifier, additional data-fields in the form of geographical location and tagged data is inserted in the document being created using create API module of the API layer (107). More particularly, in this embodiment, for every data record created using the Create API module, geographic coordinates are inserted so that geographic location data in terms of Latitude and Longitude for the datasets in the schema-less datastore (103) gets captured and that facilitate faster geo-location based query mechanism for querying the documents for manipulative operations in future. Additionally, for every data record created using the Create API module, the client application can also submit additional tags that can be used for faster querying. These additional tags are random text with comma delimited strings. In an exemplary embodiment, the texts "Electronics, TV, LCD" are considered to be a valid tags text to tag the document in the schema-less datastore

(103). The purpose of associating Tags text to the underlying data record or document is to enable faster and enhanced querying over the schema-less datastore for client-specific application needs. Such querying mechanism that enables tag-based search is also referred to as tags index-based querying mechanism.
In an exemplary embodiment a sample extensible markup language (XML) snippet defined by the create API module to create a new document in the schema-less datastore (103) includes one or more of following attributes:
• Customer Id: Unique identifier to identify the customer
• User Id: Unique identifier for the user who is sending this request
• Session Id: Unique identifier to identify client session with the server API
• Data-field Name: Name of the data-field for which the value is written to the server/datastore.
• Value: Data value for the Data-field Element Name: Name of the Element, which the Data-field is part of
• Supplement: Additional data such as Latitude (Lat), Longitude (Long) and Tags used for index-based querying of this underlying data element.
In one embodiment of the invention, the read API module in the API layer (107) is configured to define a query criterion that uses the element identifier (ID) along with other query criteria to search the documents for reading documents in the schema-less datastore. The read API module is adapted to query only those Documents that are identified with the given Element ID. Once the Documents are retrieved from the schema-less datastore. the business applications work only with the documents that are identified with the given element. In an exemplary embodiment, a sample extensible markup language (XML) snippet defined by the read API module to read at least one document from the schema-less datastore (103) includes one or more of following attributes:

• Customer Id: Unique identifier to identify the customer
• User Id: Unique identifier for the user who is sending this request
• Session Id: Unique identifier to identify client session with the server API
• Data-field Name: Name of the Data-field for which the value is queried from the server/datastore.
• Element Name: Name of the Element, which the Data-field is part of
In one embodiment of the invention, the update API module in the API layer (107) is configured to update the underlying Document retrieved using the query criteria defined through the read API module. The Update API module is adapted to update the document using the unique Identifier that's associated with it along with the updated data values. In an exemplary embodiment, a sample extensible markup language (XML) snippet defined by the update API module to update at least one document from the schema-less datastore (103) includes one or more of following attributes:
• Object Id : Object Id of Document to be updated in the datastore (103)
• Customer Id: Unique identifier to identify the customer
• User Id: Unique identifier for the user who is sending this request
• Session Id: Unique identifier to identify client session with the server API
• Data-field Name: Name of the Data-field for which the value is written to the server/datastore.
• Value: Data value for the Data-field
• Element Name: Name of the Element, which the Data-field is part of
• Supplement: Additional data such as Latitude (Lat). Longitude (Long) and Tags used for index-based querying of this underlying data element.

In one embodiment of the invention, the delete API module in the API layer (107) is configured to delete the underlying Document retrieved using the query criteria defined through the Read API module. The Delete API provides the mechanism to delete the Document. In an exemplary embodiment, a sample extensible markup language (XML) snippet defined by the delete API module to update at least one document from the datastore (103) includes one or more of following attributes:
• Object Id : Object Id of Document to be deleted in the datastore
• Customer Id: Unique identifier to identify the customer
• User Id: Unique identifier for the user who is sending this request
• Session Id: Unique identifier to identify client session with the server API
• Element Name: Name of the Element, which the data-field is part of
In one embodiment of the invention, the report API module in the API layer (107) is configured to provide a mechanism to retrieve data for a given query criteria within particular date range and/or in particular format. In an exemplary embodiment, a sample extensible markup language (XML) snippet defined by the report API module to report data corresponding to a particular search criteria includes one or more of following attributes:
• Customer Id: Unique identifier to identify the customer
• User Id: Unique identifier for the user who is sending this request
• Session Id: Unique identifier to identify client session with the server API
• Page Number: page number(optional, used in case of pagination)
• Page Size: Number of records to be returned
• Element Name: Name of element for which report is requested
• Data-field Name: Tags of element for which report is needed. (Optional, If not specified server returns report for all tags of element)

• Query: Query expression (Optional, used in case of filtering data based on query)
• Time Duration - Duration for which the data will be returned
o Start Time - Epoch value for the start time o End Time - Epoch value for the end time
In one embodiment, the correlation of defined metadata driven schema is achieved by linking of the metadata (107) with the actual datasets (documents) stored in the schema-less datastore (103) by means of information passed in the API modules. For example, each API defined by each API module incorporates an element identifier along with one or more data-fields on which the desired manipulative operations is to be performed. Additionally, values to be manipulated for the particular data-fields are also passed in the corresponding APIs. Thus, the element identifier helps in identifying the document and the data-fields are manipulated depending on the type of API called by the application for manipulating the values corresponding to the selected data-fields. Hence, though there are several documents stored in the datastore relative to various disparate applications facilitated through PaaS platform, each unique document is identified through associated metadata schema and desired manipulative operations such as CRUD along with reporting operation can be performed on the intended document as desired by the subscriber/user subscribed to the particular application facilitated through PaaS.
For example, considering the above two examples of customer-specific applications, the data model defined for both these applications in the form of metadata-driven schema (Tables 1-9) can be utilized for performing the desired CRUD operations. In an exemplary embodiment, the XML-based API embeds an element identifier 1, 2. and 3 for elements 'society, 'customer', and 'site-image respectively. Further, the data-fields and the corresponding values to be updated are passed in the XML-based

API. The element identifiers 1, 2 and 3 identifies the relevant document in the schema-less datastore (103) and depending on the type of API (create, update, delete and read) modifies/manipulates the record of the document by substituting the values of the data-fields in the document matching passed data-fields with the values passed in the XML-based APIs.
Although the invention has been described in terms of specific embodiments and applications, persons skilled in the art can, in light of this teaching, generate additional embodiments without exceeding the scope or departing from the spirit of the invention described herein.

We Claim:
1. A system (100) enabling data manipulating operations on a web-based
software platform facilitating processing of a plurality of web-based disparate
applications, the system comprising:
a) an unstructured schema-less datastore (103) comprising a collection of datasets;
b) an application processing server (101) electronically coupled with said unstructured schema-less datastore (103), the application processing server further comprising:
I. a user interface layer (105) configured to model a metadata-driven schema definition corresponding to each web-based application and to accept queries for data manipulative operations; and II. an application-programming interface (API) layer (107) configured for defining a XML-based APIs in context with the accepted queries in order to perform the desired manipulative operations on the target datasets in the unstructured schema-less datastore (103); and
c) a structured database (109) electronically coupled to the application
processing server (101) adapted to persist the defined metadata-driven
schema.
2. The system of claim 1, wherein said unstructured, schema-less datastore
(103) is a document oriented NoSQL database storing a collection of datasets
in assorted formats, each dataset comprising a field having a key-value pair.

3. The system of claim 1, wherein said structured database is a PostgreSQL database enabling persistence of the modeled schema in the form of data structure tables.
4. The system of claim 1, wherein said API layer (107) provisions one or more XML-based API modules including a create API module, a read API module, an update API module, a delete API module and a report API module configured to perform the manipulative operations of create, read, update, delete and report respectively on the schema-less datastore (103).
5. The system of claim 1, wherein said create API module facilitates provision of geospatial queries and tag-based index querying mechanism for enabling quick and easy future data search on the schema-less datastore (103).
6. A method enabling data manipulating operations on a collection of datasets with assorted data formats relative to various disparate web-applications stored in an unstructured, schema-less datastore characterized by identifying the target dataset for manipulation using a metadata-driven schema persisted in a single structured database, the method comprising processor implemented steps of:

a) provisioning a user interface to model a metadata driven schema for disparate dataset assorted data formats, wherein said schema is defined with a metadata in the form of one or more elements and one or more data-fields;
b) persisting the modeled schema in a structured database provisioning storage of said elements and said data-fields in the form of array of structured records;

c) provisioning an Application Programming Interface (API) layer to enable a user to initiate a request call for performing at least one manipulative operation on the datasets in the unstructured schema-less datastore pertaining to at least one web-based application;
d) defining a XML-based API in response to said user call request embedding at least one element identifier in the form of a key and passing one or more data-fields along with values to be manipulated corresponding to said one or more data-fields through the persisted metadata-driven schema; and
e) performing the desired data manipulative operation on a target dataset identified through the embedded element identifier, geospatial and index-based querying mechanism to manipulate the data-fields with the values embedded with the passed data-fields in the XML-based API.

7. The method of claim 6, wherein said unstructured, schema-less datastore is a document oriented NoSQL database storing a collection of datasets in assorted formats, each dataset comprising one or more fields having a key-value pair.
8. The method of claim 6, wherein each element is a collection of one or more data-fields.
9. The method of claim 8, wherein said element can include one or more attributes selected from a group consisting of an element identifier, an element name, an element description or combinations thereof.

10. The method of claim 8. wherein each data-field consists of a unique identifier, descriptive name, data-type, an identifier of element to which the underlying data-field belongs or combinations thereof.
11. The method of claim 10, wherein said data-field can have a data-type selected from a group consisting of boolean, integer, long, float, string, date, image, timestamp, time-duration, Base64, audio, video, binary data or combinations thereof.
12. The method of claim 7, wherein said key can be a name having data type as string while value can be a value of any data type, a dataset itself, an array of values or combinations thereof.
13. The method of claim 6, wherein said XML-based API can include a create API, a read API, an update API a delete API and a reporting API configured to perform the manipulative operations of creating, reading, updating, deleting and reporting respectively on the schema-less datastore.
14. The method of claim 6, wherein said geospatial querying is enabled by attaching geographical location data to a newly created dataset in a datastore using a create API module.
15. The method of claim 14, wherein said geographical location data is captured in terms of Latitude and Longitude co-ordinates corresponding to the actual location of the created document.

16. The method of claim 6, wherein said index-based querying mechanism is enabled by inserting additional tags data in textual form with comma delimited strings in the newly created document using a create API module.
17. The method of claim 6, wherein said desired manipulative operation is performed on the retrieved dataset in accordance with the data-field information embedded in the XML-based API.
18. The method of claim 6. wherein said modeled schema is persisted in the structured database in the form of data structure tables storing data-fields and associated content thereof for each element.