While working with DatumNode Service client applications has no idea what query or stored procedure they are actually executing and the databases they are interacting with. Instead clients deal with the data abstraction layer. This middle-tier represents internal database objects (tables, queries, stored procedures, connection strings, etc) which differ greatly in various databases as business objects which describe subject area. The logical structure is represented by a hierarchical tree.
Solution - object representing one of the information systems that completely describes some part of the subject area. For example: billing subsystem, order subsystem. Solution consists of projects.
Project - represents one of functional modules of the solution. It’s much like application using in the context of some information subsystem. For example billing subsystem may have application for managing information about clients for viewing\updating\inserting some information about the clients, accounts, rates, etc. Project consists of entities.
Entity - represents business objects which are used in projects (applications). For example, application for managing client’s information works with the entity "client". In DatumNode entity represents some abstract object which in turn is represented by any combination of tables, views of different data sources. Entity has a set of commands.
Command - represents some kind of action that can be executed against entities. In database commands are represented by queries and stored procedure but, unlike them, in DatumNode Service commands describe some business actions instead of inner database structures. For example entity "client" may have such commands: "get_cient_info", "add_client", "delete_client" and so on.
Parameters - in general, parameters have the same meaning as any other parameters using in procedures and functions. Beyond this there is an opportunity to set up the behavior of the parameters: in case of "system" or “constant” you can set up some predefined value that will be used automatically as a parameter.
Data source - Another important object that stands beyond hierarchical tree is Data source. This object represents by its name some "logical data source" and contains all the required information for connection to the database: connection string, provider, etc.
Data source reference - In order to use data source each object must have a data source reference. This object represents some part of the connection string that can differ for different users or objects (usually data source reference contains user name and password). Like any other object data source reference has its own set of security permissions which makes it possible to set up database credentials (or other parameters) for each user independently.
All objects (except data source itself) can have any number of data source references with its own permissions. If some object doesn’t have any data source references then the data source references of the objects that stand higher in the hierarchal tree will be used.
If an object has more than one data source references with the same permissions then the data source reference with the highest priority will be used ( if it was not directly specified in the request string, of course). You can change the priority of the data source reference by changing its position in DatumNode Explorer.
Connection - Data source reference, in turn, can have any number of connections. Connection is the object that represents some part of the data source’s connection string that can differ for different users (for example user name and password, needed to connect to the database). As any other objects in DatumNode Service connections have theirs own permissions.
Request string - Client applications interact with DatumNode Service using request string which has the following format:
data source reference.connection.solution.project.entity.command
You can use "*" instead of data source reference and connection:
*.*.solution.project.entity.command
In this case data source reference and connection will be set up automatically according to object’s priority and security permissions.
The resulting connection string consists of constant and variable parts. The constant part is the attribute "connection" of the data source (which, in turn, is specified by the target data source reference –attribute "data source"). The second part can be found in several places:
- If the data source reference has any connections (and the current user has sufficient security permissions) then its attribute "connection" is used. If there are more then one connections then connection with the highest priority (position in the object tree) will be used
- If the data source reference has no connections then its attribute “Default Connection” is used (if it is not empty).
- If data source reference has an empty attribute “Default Connection” then the same attribute of the data source will be used as a default connection.