Frequently Asked Questions
- 1 Event Tracing in RadixWare
- 2 Description of Presentation Entity Adapter Class
- 3 Types of Properties in RadixWare
- 4 Setting up Custom Property Editor instead of Standard One
- 5 System of Access Rights in RadixWarе
- 6 Architecture of System Based on RadixWare Platform
- 7 Base Presentation and Replaced Presentation Parameters in Editor of Editor Presentation
- 8 Difference between Static Class and Dynamic Class Catalogs
- 9 checkExistence Parameter in loadByPk() Method of Entity Class
- 10 init() Method of Entity Class
- 11 Dependency between Property Values
- 12 Published Flag in Definition Editor
- 13 Difference between Definition Overwriting and Overriding
Event Tracing in RadixWare
How can I set up:
- event tracing in Radixware,
- event display in the trace,
- event tracing for certain system objects: instances, systems units, ARTE pool?
To answer these questions, let’s consider the RadixWare Server structure and peculiarities of the application server operation. The application server structure is presented on the diagram below:
Instance (running instance of the application server) consists of the following objects:
- Instance object (instance itself) that exists in a single copy. It is used to load and run system units, manage ARTE pool, and perform periodic service operations.
- System units. The function of a certain unit depends on the unit type.
- ARTE instances - separate Java threads used by the system to process requests coming to ARTE units. Each thread associates with the entity cache and own copy of classes described in the ADS segment.
Instance thread - the first thread run by the server. The instance reads the list of units, initializes and starts the units. The instance also creates and controls the ARTE pool (a set of ARTE instances), i.e. initializes the ARTE pool and controls whether the ARTE pool size complies with the instance settings (for an instance it is possible to set the minimum and maximum size of the pool). The pool size is controlled by starting new instances or stopping the started ones if required.
Most system units (Job Executor, Job Scheduler, notification units, etc.) use their own threads of control. The ARTE unit operation is organized in a different way:
- When the unit is started, a server socket is created and the unit waits for the network connection.
- After the unit accepts the network connection (but before it starts reading the incoming data, i.e. after the ServerSocket.accept() method is called), it connects to the free ARTE instance from the pool and transfers the current connection to this instance for further processing. Afterwards, the selected ARTE instance continues working with the connection and the unit waits for the next connection. If the pool does not contain free ARTE instances:
- a new instance is created (if the pool size allows)
- if the number of started instances exceeds the maximum size of the pool, SOAP Fault "Unit is busy" is sent as response to the connection request.
- The selected ARTE instance reads and processes the request received via the connection (selects data from the database, calls the command or method of a certain class, etc., and sends a response).
System Events Tracing
The trace can be written to a database table, to a file on a local drive or can be displayed on a screen (in case the RadixWare Server instance is started in GUI).
System instances, system units and ARTE instances have own trace objects (instance.getTrace(), unit.getTrace(), arte.getTrace()).
The Trace.put() methods used in the RadixWare Designer program code write the events to the trace of the ARTE instance in whose context the code is executed (the program code is always executed in the context of an ARTE instance that can be accessed by the Arte.getInstance() method).
The kernel code (code of instance and code of units) builds the traces of units and system instances. The instance trace contains the information on events relating to units loading and ARTE pool control. The unit trace contains specific information depending on the unit class (for example, the ARTE unit trace contains the information on problems occurred when creating the server socket or problems of reading the unit settings from the database).
The trace parameters are defined in the trace object editor of RadixWare Desktop Explorer:
- The instance trace parameters are defined in the instance editor (Entire System | System Settings | System Instances). The instance trace is displayed on the Trace page of the application server main window
- The system unit trace parameters are defined in the unit editor (Entire System | System Settings | System Units). The system units trace is displayed on the Units page of the application server main window and in the dialog boxes of units. If the messages written to the ARTE trace comply with the trace profile of the ARTE instance and unit, they are also copied to the trace of the unit that initiated the request. For example, if it is required to display the ARTE debug trace in the unit file trace, set the file trace profile to Debug for both the instance and unit.
- The ARTE unit trace parameters are similar to those of the own system (Entire System | System Settings | Systems | <Own System>). The ARTE units trace is displayed on the ARTE Pool page of the application server main window.
Description of Presentation Entity Adapter Class
What is the Presentation Entity Adapter class used for?
Presentation Entity Adapter classes are used as intermediary between EAS and entity instances. They implement specific functionality (for example, additional checks) when working with the entity class instances from the client application.
When a request to modify / delete an object is received, EAS starts working with the entity instance (that represents this object) indirectly by creating a presentation entity adapter class and passing the entity class instance to the constructor of this class. Subsequently, the presentation entity adapter class is used to call methods and access properties of the entity class. This mechanism allows modifying or rolling back the actions being executed on the entity instance. Some methods of the adapter can be overridden. The list of methods available for overriding allows defining what actions (executed on the entity class) can be modified in the adapter.
Types of Properties in RadixWare
What are the types of properties in RadixWare?
The RadixWare platform supports the following types of properties:
- Column-Based Property
- Detail Property
- User Property
- Parent Property
- Expression Property
- Dynamic Property
- Event Code Property
Column-based property is the main type of properties that are stored in the columns of DB tables. Properties of this type are available for classes derived from the Radix::Meta::Entity class only (classes of entities and application classes). A set of data types for this property is restricted. RadixWare starts reading the property value from the DB table after obtaining access to this property. Properties of this type include two categories:
- Primitive properties. The data type of the property value is similar to that of the value stored in the DB table.
- Parent references. These properties are created by the reference between tables and provide the access to the related objects. Presence of references between tables in the DDS segment defines the possibility of creating a property of this type, and the property value, in fact, can depend on several columns (primitive properties) in the table.
One primitive property and one parent reference can correspond to a table column at a time.
Detail properties are properties of application classes stored in the columns of detail tables.
This type of properties is similar to the column-based properties. The only difference is that the values of these properties are stored in one of seven user property tables (but not in the main or detail table). All user property tables have the same structure:
|Column Name||Column Type||Column Description|
|defId||Str||Unique ID of the user property|
|ownerEntityId||Str||Unique ID of the class the property belongs to. The ID of the entity class or application class can be used as a column value.|
|ownerPid||Str||String representation of a primary key for the record (stored in the table) the class with the ownerEntityId ID is based on|
|val||Depends on the table||Value of the user property|
The user property tables are listed below:
|Table Name||Type of val Column||Description|
|UpValBLOB||Blob (RADIX synonym: java.sql.BLOB)||Stores binary data (BLOB)|
|UpValСLOB||Clob (RADIX synonym: java.sql.CLOB)||Stores string data (CLOB), for example, XML documents as well as all array properties.|
|UpValRef||Str (RADIX synonym: java.lang.String)||Stores properties of the Parent Reference type: the val column stores string representation of a primary key for the record the property refers to.|
|UpValRaw||Bin||Stores binary data|
|UpValStr||Str (RADIX synonym: java.lang.String)||Stores strings|
|UpValNum||Num (RADIX synonym: java.math.BigDecimal)||Stores integers and floating-point numbers|
|UpValDateTime||DateTime (RADIX synonym: java.util.Timestamp)||Stores time stamps|
The value array property is a type of user properties. Arrays are stored as CLOB and have the following format:
// The value consists of the number of elements and elements in the specified number. value = count element*; count = [0-9]+; element = '[' size ']' data; size = [0-9]+; // The content of the data field depends on the type of the array values. data = <number of characters equal to size>;
Array of Strings (ArrStr)
The data field stores the string value.
| The array containing the Green and White values will be stored in the following format:
Array of Real Numbers (ArrNum)
The data field stores the value in the decimal format.
| The array containing the values 10000.00 and 10003.29 will be stored in the following format:
Array of Integers (ArrInt)
The data field stores the value in the decimal format.
| The array containing the values 56 and 567 will be stored in the following format:
Array of Enumerations (Arr<?>)
Arrays of enumerations are stored as arrays of strings/numbers/characters (depending on the enumeration type) including enumeration values. The data field stores the value of the enumeration item: data = <enumInstance.Value>.
| The array containing the values MetricKind:Inst.Stop and MetricKind:Inst.CpuUsage will be stored in the following format:
Array of References (ArrParentRef<?>)
Arrays of references are stored as arrays of strings of GUID classes present in the array, and PID of certain objects. The data field stores the reference in the following format: data = GUID '\n' PID.
| The array containing the references to user1 and user2 (instances of the Radix::Acs::User class) will be stored in the following format:
2tblSY4KIOLTGLNRDHRZABQAQH3XQ4 user1tblSY4KIOLTGLNRDHRZABQAQH3XQ4 user2
Changing Type of User Property
To avoid losing stored values when refactoring the type of user property, in the DDS segment of the layer that contains the class being edited, add the script to move the property values from the current table to a new one. Otherwise, the property values will be lost. To generate the respective script, execute the Generate re-create script command (the Main page in the table definition editor). The generated script can be adjusted manually (if necessary).
Parent properties allow adding to the current class the properties (already existing in this class) of an object available via Parent Reference. Properties of this type can be stored in the columns of the parent table (linked to the current table by one-to-many relationship) or ancestor table (for example, a table that is parent in relation to the parent table of the current table). The depth of transitions between tables is unrestricted.
Properties of this type consist of SQL expressions. They allow using selector and filter conditions in SQML code.
Dynamic properties are the general-purpose properties presented as fields of Java class that can be accessed by get() and set() methods. Dynamic properties can be of any type and available for any class.
Event Code Property
Event code is a special type of string used to log events to the trace. When logging an event, the event code and parameters to be inserted into certain code sections (the sections have the following format: %<number>) are saved.
Event codes localization allows displaying messages in the language used in RadixWare Desktop Explorer. So when logging messages to the trace it is recommended to use event codes (by means of the Radix::Arte::Trace:put() method) instead of methods that accept the prepared message string.
Event code property allows storing event codes as properties if these codes need to be used more than once. It is strongly recommended not to store the event code property in the fields of the string type. In this case, it becomes impossible to quickly edit localized messages relating to this property. Properties of this type are available for any class.
Setting up Custom Property Editor instead of Standard One
The PropEditor (property editor) has been added to the form. What settings should be made to use the custom property editor in PropEditor?
To create a property editor in the custom View class, the Radix::Explorer.Models.Properties::Property:createPropertyEditor method is used. It is possible to override this method in the property presentation in the client model and return the instance of the own class in the result. For the Explorer environment, this class must extend the Radix::Explorer.Widgets::AbstractPropEditor class.
If required, the custom modal dialog box (for editing the property) can be set up in the editor of the definition of this property. In the Custom dialog area of the Presentation page, select the definition of the dialog box (for editing the property) for the Explorer and Web environments.
System of Access Rights in RadixWarе
- What is the Administration group of a user (the parameter is defined in the branch Entire System | Administration | Users | <User> | General page)?
- Why is it impossible to add / edit / delete roles on the Own Roles page of the current user editor (Entire System | Administration | Users | <User>)?
- What are the rights of the users listed on the Administered Users page of the user group editor (Entire System | Administration | User Groups | <User Group>)?
1. The system of access rights in RadixWare provides the facility to split any entity into selections relating to partitions. The user group table can serve (and, actually, does) as a table containing partitions (access partitions) for the user table. The Administration group parameter of a user defines the user account access rights.
2. The system of access rights in RadixWare is organized in such a way that a user cannot add roles and user groups (having assigned roles) to himself because extending own privileges contradicts to the principles of the system secure operation. It is also prohibited for a user to delete own roles because, subsequently, it will be impossible to add the roles again. Besides, a user cannot assign the roles exceeding own privileges to another user / user group.
3. The Administered Users page contains the list of users for whom the current group is defined as the administration group.
Architecture of System Based on RadixWare Platform
What are the system, service, access point, service client profile? How do these objects communicate?
System is a part of the application software suite that consists of several instances. The system is used to store the global settings that can be referred to all objects. RadixWare–based system has a three-tire architecture, including the following tires:
- DB Server. The database is used to store all the application data.
- Application server. RadixWare Server is used as the application server.
- Client applications. RadixWare Explorer is used as the client application.
The general scheme describing the interaction between the system components is provided below:
The system based on the RadixWare platform can interact with other systems via SOAP protocol or other protocols.
The application server can include several RadixWare Server instances, thus ensuring the system scalability and fault-tolerance. Each instance represents an independent OS process. As a rule, each instance is started on a separate cluster node. When connecting a client to the application server, the service infrastructure automatically selects available instances and balances the load between them.
Each instance can include a set of system units defined for it. Each unit starts one or several execution threads. Some units provide services - the system interfaces available via SOAP protocol. Other units of the system, the client application or other systems can use the available services.
When setting up the service, the user is offered to select the service access channel. Available values:
- TCP. The service is available via TCP/IP network protocol.
- Internal channel. The service is available only for other units of the same instance
- JMS. The service uses the JMS channel
The internal channel has the following advantages over the TCP channel:
- Performance. Using the internal channel allows to avoid the costly network connections.
- Security. The services using the internal channel are not accessible over the network, and therefore do not require SSL protection or any other specific security procedures.
|The services using the internal channel cannot be used by the units of other instances.|
The services can be provided by the RadixWare units and instances as well as by the external system components.
The services are accessed via the access points (Service Access Point). Each service can be assigned several access points.
The access point defines the following:
- unique network address
- accessibility: for other units of the same system only, for other systems and explorer, or for all systems and units
- security settings
The clients using the services can be:
- units of the same system
- other systems
- operator stations
The client access to the services via particular access points is set up using the client profiles (Service's Client Profile). The client can be assigned a certain profile or no profile at all. The many-to-many relationship with the respective priority is established between the profiles and access points. For each client request to a particular service of a particular system, the access point is defined as follows:
- If the client is assigned a profile, the access point is randomly selected from the available access points linked to the profile. The access points with the highest priority are selected more often.
- If the client is assigned no profile, any access point is selected.
Base Presentation and Replaced Presentation Parameters in Editor of Editor Presentation
What is the difference between the Base presentation and Replaced presentation parameters in the editor of the editor presentation?
The Base presentation parameter defines the base presentation of the editor (the base presentation of the selector is specified in the Base selector presentation parameter of the selector presentation editor). It is used to build the presentation hierarchy using the inheritance mechanism that allows to minimize the time used to describe each element.
The Replaced presentation parameter is available only in the editor of the editor presentation. It defines the presentation that is replaced by the current presentation in the objects that are the instances of the class defining the current presentation or objects derived from this class.
The parameters are not editable if the current presentation is the only for the editor of this class and its base classes.
For parameters of the editor of the editor presentation, refer to RadixWare. Programmer Guide / Definition Type / Application Definition Segment / Presentation Definitions / Editor Presentations/ Editor of Editor presentation.
Difference between Static Class and Dynamic Class Catalogs
What is the difference between the Static Class Catalog and Dynamic Class Catalog?
The class catalogs allow a user to select the required class when creating a class instance in the client application (for details on class catalogs, refer to RadixWare. Programmer Guide / Definition Type / Application Definition Segment / Presentation Definitions / Class Catalogs).
Dynamic Class Catalog (the most frequently used catalog) is described in the base class of the class inheritance hierarchy and overridden in the child classes. The peculiarity of the dynamic class catalog is the way it is extended: to add a class to the dynamic class catalog, override the base catalog (the catalog defined in the base class of hierarchy) in this class and add a reference to the class where it is overridden to the base catalog. In the course of the RadixWare Designer functioning, the base catalog of classes will be merged with the catalogs of all child application classes.
Static Class Catalog cannot be extended in the child classes. The static class catalog can contain sections and unlimited number of references to classes based on the class where the catalog is described. This catalog should be used if the number of classes is known beforehand and is not to be changed. Practically, the static class catalogs are rarely used.
The advantage of the dynamic catalog is that it can be extended unlimited number of times, whereas, the static catalog can contain only those classes that are in the scope of the catalog owner.
checkExistence Parameter in loadByPk() Method of Entity Class
What does the checkExistence parameter in the loadByPk() method of the (Entity) entity class affect? How does this parameter affect the user properties of the entity class object?
The checkExistence parameter defines whether to make a request to the DB when building the object of the entity class.
The loadByPk() method is used to read the object from the DB by the primary key (PID). When calling this method, the following actions are performed:
1.The system searches for the already created instance of the entity class by the specified PID in the ARTE cache. If the required instance is not found, a new instance of the entity class is created. For this purpose, the system detects whether the instance class supports the application classes using the class metainformation:
- If the application classes are not supported, the class constructor is called using the reflection mechanism.
- If the application classes are supported, it is required to find out the actual value of the classGuid property before building an object. For this purpose, the request to the DB is executed (irrespective of the checkExistence value). To optimize the classGuid request, the system reads all own properties of the object from the DB (that is the properties that are stored in the DB without the details and user-defined properties). Once the object is built, the values of the obtained properties are filled and the object is marked as read.
2. If checkExistence == true and the object is not marked as read, the object properties are read from the DB (the entity.read() method is called).
3. The obtained object is returned. The loadByPk() method returns null if no object with the specified PID is found when reading the object from the DB (when loading the classGuid value or reading the object if checkExistence == true).
Taking into account the loadByPk() method operation mechanism and the checkExistence parameter description, the following conclusions can be made:
- When calling the loadByPk() method with the same PID and checkExistence == true several times, only one request to the DB is executed. First, the object is created, marked as read and moved to cache. Subsequently, when calling the object, it is extracted from cache and the request to read the object from DB is not executed as the objects are already read.
- If the class of instance obtained using the loadByPk(pid, false) method does not support the application classes and the system addresses only the properties that are a part of the object primary key, no DB request is made. In this case, there is no guarantee that the object exists in the DB.
- If checkExistence == true and the loadByPk() method returns the object, it can be affirmed that from the beginning of the current ARTE request processing the object has been read at least once and exists in the DB when being read.
- If the entity supports the application classes, the value of the checkExistence parameter does not affect the loadByPk() method, as the DB request for reading the complete object will be executed in any case.
The checkExistence parameter affects the user-defined properties of the entity class object as follows:
- If the object is not marked as existing in the DB (the object is marked as existing after the successful execution of the first request to the DB), the value of the user-defined property will be always null.
- The loadByPk() method with checkExistence ==false does not affect the attribute indicating the object presence in the DB. Therefore, the value of the user-defined property can be incorrect after calling the loadByPk() method with checkExistence ==false.
init() Method of Entity Class
What actions are performed at the level of the java object and DB level when calling the init method of the entity class? Is there any recommended method for creating the entity class instance? When is it recommended to call the init method: after constructor call or in the constructor body? Is the following source code correct?
SomeEntity obj = new SomeEntity(prop1, prop2.... ); obj.init();
When calling the init method, the following actions are performed:
- The system checks whether the object is new and has not been initialized yet (otherwise, an exception occurs).
- The beforeInit() method is called.
- Java objects are initialized. These objects ensure functioning of the user-defined properties and details.
- The values from the obtained src are written to the object properties; if src is null, the default values are written.
- If the object has the classGuid property, Id of the current class is written to it.
- For the properties whose values are obtained from Sequence, the request to DB is executed. The obtained value is written to the property.
- The entity is assigned the INITIED state.
- The afterInit() method is called.
The example of the source code provided in the question is not correct, as the entity is not provided with the constructor that can obtain the property values. Therefore, the entity properties should be read and written after it is assigned the INITIED state, that is after calling the init() method or in the afterInit() method.
SomeEntity obj = new SomeEntity(); obj.init(); obj.prop1 = 'xxx'; obj.prop2 = 'yyy';
Dependency between Property Values
Two properties are added to the editor presentation page. The value of one property is calculated by the get() method basing on the value of the other property. How to set up the automatic update of the first property when the second property value changes?
You should publish the main property (the property whose value affects the value of the calculated property) in the model (the Model definition that is child in relation to the editor presentation). In the editor of the main property presentation, add the calculated property to the list on the Dependent items page. If you set up the system as described above, the calculated property value will be automatically updated when the main property value changes.
Published Flag in Definition Editor
When should I set the Published flag in the definition editor? Can I overwrite/override the definition with the Published attribute by the definition without this attribute?
The Published flag should be set in the definition editor if this definition is to be used in the definitions of the upper layers and user-defined functions (refer to RadixWare. Programmer Guide / RadixWare Designer User Interface / Standard Control Elements / Select Access Mode).
The definitions without the Published attribute cannot be overwritten, as it is possible to overwrite the definitions only between the layers.
It is possible to override the definition with the Published attribute by the definition without the particular attribute within one layer, but it is impossible to use the overriding in the upper layers. In the upper layers, only the original definition with the Published attribute will be available.
Difference between Definition Overwriting and Overriding
What is the difference between the definition overwriting and definition overriding?
To overwrite a definition means to completely replace the definition, whereas the definition overriding implies keeping both the original and overriding definitions.
The overwritten definition always has the same GUID. Therefore, once it is re-defined, any code that called the original definition before, now will call the overwritten one. The definition can be overwritten only if its parent definition is also overwritten. The definitions can be overwritten only between the layers. The definition can be overridden only if its parent definition is inherited from another definition.
For details on definition overwriting and overriding in RadixWare, refer to RadixWare. Programmer Guide / Main Objects of RadixWare Platform / Inheritance and Overriding and RadixWare. Programmer Guide / Main Objects of RadixWare Platform / Overwriting Definitions.