Differences

This shows you the differences between two versions of the page.

--- docs:2500_config_apps:2300_external_sys_ldap [2025/04/28 08:31] – ↷ Page name changed from docs:2500_config_apps:2800_external_sys_ldap to docs:2500_config_apps:2300_external_sys_ldap aware_admin
+++ docs:2500_config_apps:2300_external_sys_ldap [2025/06/12 02:34] (current) – Rename to AwareIM aware_support3
@@ Line 2: / Line 2: @@
 ====== Working with Data Stored in Existing Database Tables or LDAP ======
-As explained in section [[docs:2000_concepts:0500_data_storage|Data Storage]] //**Aware IM**// automatically creates, alters and deletes database tables. This is great when you want to create new applications, but what if you need to use existing data stored in database tables created by other software or in network servers such as LDAP? There are at least two scenarios when you might want to do this:
+As explained in section [[docs:2000_concepts:0500_data_storage|Data Storage]] //**AwareIM**// automatically creates, alters and deletes database tables. This is great when you want to create new applications, but what if you need to use existing data stored in database tables created by other software or in network servers such as LDAP? There are at least two scenarios when you might want to do this:
-  - You have a legacy system that you want to completely transfer to //**Aware IM**//.
+  - You have a legacy system that you want to completely transfer to //**AwareIM**//.
-  - You have an existing database software system(s) (or network server) and you want to continue using this system, however, you also want to add an extension to this system to be managed by //**Aware IM**//.
+  - You have an existing database software system(s) (or network server) and you want to continue using this system, however, you also want to add an extension to this system to be managed by //**AwareIM**//.
-For the first scenario the recommended approach is to configure a new application using //**Aware IM**// and then transfer the operational data from the legacy database into //**Aware IM**// using [[docs:3400_how_to:1100_miscellaneous:1360_import_export_date|Export/Import]].  For the second scenario you can get //**Aware IM**// to use the data stored in the existing database tables or network server by configuring business objects with persistence option ''Database: existing external'' or ''LDAP'' (see [[docs:2500_config_apps:0500_add_edit_objects:0100_specify_gen_props|Specifying General Properties]]). With this approach you can configure new business objects managed automatically by //**Aware IM**// but also have business objects that will be shared between //**Aware IM**// and other software systems or network servers that already use the data. You can get //**Aware IM**// to write to the existing database tables or network servers or you can only perform queries on such objects.
+For the first scenario the recommended approach is to configure a new application using //**AwareIM**// and then transfer the operational data from the legacy database into //**AwareIM**// using [[docs:3400_how_to:1100_miscellaneous:1360_import_export_date|Export/Import]].  For the second scenario you can get //**AwareIM**// to use the data stored in the existing database tables or network server by configuring business objects with persistence option ''Database: existing external'' or ''LDAP'' (see [[docs:2500_config_apps:0500_add_edit_objects:0100_specify_gen_props|Specifying General Properties]]). With this approach you can configure new business objects managed automatically by //**AwareIM**// but also have business objects that will be shared between //**AwareIM**// and other software systems or network servers that already use the data. You can get //**AwareIM**// to write to the existing database tables or network servers or you can only perform queries on such objects.
-When you define a business object with the ''Database: existing external'' or ''LDAP'' persistence options //**Aware IM**// will automatically import columns of the required database tables or data definitions of the network server and convert them into business object attributes. You will not be able, however, to add your own attributes to such objects(except shortcuts to reference attributes).
+When you define a business object with the ''Database: existing external'' or ''LDAP'' persistence options //**AwareIM**// will automatically import columns of the required database tables or data definitions of the network server and convert them into business object attributes. You will not be able, however, to add your own attributes to such objects(except shortcuts to reference attributes).
-For existing databases you will also need to designate one or more columns in the existing database tables as primary keys for the table that uniquely identify a record in the table (for example, a unique id of a customer or a combination of his first and last name etc). If you do not define a primary key for a table //**Aware IM**// will be able to perform queries on such tables but it will not be able to dispay details of particular records, insert new records or delete the existing ones. For a LDAP server you will need to specify a distinguished name of a sample record in the LDAP server for //**Aware IM**// to be able to read the data definition of the record.
+For existing databases you will also need to designate one or more columns in the existing database tables as primary keys for the table that uniquely identify a record in the table (for example, a unique id of a customer or a combination of his first and last name etc). If you do not define a primary key for a table //**AwareIM**// will be able to perform queries on such tables but it will not be able to dispay details of particular records, insert new records or delete the existing ones. For a LDAP server you will need to specify a distinguished name of a sample record in the LDAP server for //**AwareIM**// to be able to read the data definition of the record.
-As you can see this approach has certain limitations (they are summarized below) and is, therefore, only recommended when all other approaches are not practical. These limitations are the reason we recommend using export/import for the first scenario when you want to transfer a legacy system to //**Aware IM**//.
+As you can see this approach has certain limitations (they are summarized below) and is, therefore, only recommended when all other approaches are not practical. These limitations are the reason we recommend using export/import for the first scenario when you want to transfer a legacy system to //**AwareIM**//.
 ==== Limitations of using data stored in existing database tables or LDAP ====
-  - You can only use attributes automatically created by //**Aware IM**// from the database tables or network server. You cannot define your own attributes (except shortcuts).
+  - You can only use attributes automatically created by //**AwareIM**// from the database tables or network server. You cannot define your own attributes (except shortcuts).
-  - Some types of database columns cannot be imported into //**Aware IM**//. //**Aware IM**// will ignore such columns.
+  - Some types of database columns cannot be imported into //**AwareIM**//. //**AwareIM**// will ignore such columns.
-  - If you do not define a primary key for imported columns //**Aware IM**// will not be able to display details of individual records, create new records or delete the existing ones.
+  - If you do not define a primary key for imported columns //**AwareIM**// will not be able to display details of individual records, create new records or delete the existing ones.
   - You cannot mix objects with different persistence types in one query. For example, the query<code aim>FIND Order WHERE Order.Customer.Name = 'John' </code> will not work if Customer object is stored in the existing database.
   - The use of external tables and network servers can make the design of your application less portable as it will depend on specific connections to existing databases and network servers.