RadixWare Administrator Guide/RadixWare Support

From RadixWiki
Jump to: navigation, search

Related Documents

The following documents are recommended for additional information:

Conventions and Abbreviations

Conventions

Convention Example Applies to
Bold RadixWare Starter application First mentioned terms; user interface elements; names of the software products
Bold italic For the notifications description, refer to RadixWare. Software Products Installation and Upgrade Technology. Names of the documents
Underlined After the update package creation, the application will offer to sign the created zip file. Reference to a topic / section / subsection / page within the document


Abbreviations

API Application Programming Interface
DS Digital Signature
OS Operating system
SVN Subversion

Overview

Basic Concepts

Product release - a state of the product at a certain point of time. It is identified by compound number, for example, 1.22.3.

Database script - a set of SQL queries changing the database structure.

Offshoot branch - a development branch containing the corrections for the software product release. It is identified by the number of the source release with one component added, for example 1.22.3.2.

Unit - a compound part of the product. Different customers can receive different sets of units. For details, refer to RadixWare. Programming Guide.

Distribution kit - a set of files that the customer uses to install or update the software product. It includes a certain set of units.

Initial installation package - a zip file containing the distribution kit files. It is submitted to the customer as the first distribution kit. The initial installation package is a particular case of the update package.

Update package - a zip file containing the distribution kit files used to update the software product.

Vendor and Customer Interaction Scheme

The process of software product distribution can involve several parties. Each party fulfills a particular function. The vendor develops the software product and provides it to the customer. The customer can operate the software product independently. In addition, the customer can act as a developer, i.e. make the developments for their own use or to pass the product to their customers. In the latter case, the developer acts as a vendor towards its customers. Therefore, the participants make a chain where the same organization can have several functions:

Clients.png

The software product received from the vendor can contain one or several layers that include a set of units defined by the contract. The developer works in one or several programming layers. These layers form a tree with the basic programming layer at the root and the customer modifications at the upper layers. The customer modification layers can exist not for all customers, just as not all the customers have their own programming layers. All the software product components and files are stored in the SVN repository. Using SVN enables to organize development and product support for the participant and allows to manage several product versions.

Example.jpgLet us assume that the participant develops Radinsk -based software for their customer. In this case, the tree includes three layers: org.radixware, org.radixware.radinsk and customer modification layer (org.radixware.radinsk.client_1).

If this participant develops another software product based on Radinsk for another customer, the org.radixware, org.radixware.radinsk and org.radixware.radinsk.client_2 (customer modifications layer for the second customer) layers must be located for this participant in the separate development branch.

The RadixWare platform is a tool enabling to manage such stages of the product life cycle, as development, testing, commissioning, customer support and database structure maintenance. This tool is provided by the RadixWare Manager application.

Database Structure Support

In the course of software product maintenance and operation, several databases can be used on the RadixWare platform:

  • the database for testing
  • the database for commercial operation

RadixWare Manager enables to perform deployment and structure upgrading of all these databases.

Example.jpgThe test DB can be used to test the particular software product version and to start the software product in the development mode. For details on how to start the software product in the development mode, refer to RadixWare. Programmer Guide / Starting RadixWare Server and RadixWare Explorer in Development Mode.

The product database structure is modified by executing scripts. The scripts are stored in the common directory of the scripts repository. The directory contains the scripts of all product versions and all scripts of transitions between the versions for all product layers that are not localizing ones. A set of scripts that define the database is the same for all customers. The transition scripts are created in the course of product development and stored in the development catalog of the dev repository. When creating the release, the transition scripts are transferred from the development branch to the common catalog of the scripts repository, the creation scripts are created automatically for each release. To bring the database structure into agreement with a particular release, the developer creates the script packages. Their executing transfers the database structure from the actual release to the required one. At that, it is taken into consideration that the upper layer script executing requires to bring into agreement the lower layers structure. At the issue of release, in the common script directory, the following script packages are compiled for each development layer:

  • pre-upgrade (the scripts are executed before upgrading from the previous release)
  • the scripts of transition from the previous release to the new one
  • post-upgrade (the scripts are executed after upgrading to release)
  • the scripts of initial release installation ("from scratch")

The created update package comprises the corresponding set of script packages for transferring between the product versions and the script package of initial installation for all delivered product layers. When the customer receives the update package, the scripts are recorded in the common directory of the scripts repository in the course of the distribution kit loading by means of RadixWare Manager application. During the product installation/ updating, the database structure is brought into agreement with the certain product release. The result of script executing is automatically recorded in the service table of the processed scripts recording (RDX_Dds UpgradeLog). Moreover, the database structure for the customer is modified at the receiving of fix packages from the vendor and at the release issue of the product in the course of own development. The script executing errors occurred when installing / updating the product are fixed by the vendor. For this purpose, the customer delivers to the vendor the script executing log file with the error description. On the basis of this file, the vendor creates the fix package which contains the fixed script and the script of the fix. After that, the vendor sends it to the customer; the latter receives the fix package and performs the product installation / updating again. The scripts that change the database structure can either support or not support "hot updating" (changing the database structure when running RadixWare Server). If it is occurred that at least one of the scripts does not support the "hot updating", the user receives the warning requiring to restart RadixWare Server.

Main Stages of Product Lifecycle for Customer

  • Interaction with Vendor.
  1. Receiving the product distribution kit (initial installation package or update package) from the previous participant - the platform vendor.
  2. Loading distribution kit to the repository.
  • Testing.
  1. Putting the product into testing to check its operability.
  2. The test database installation (when installing the product for the first time) or updating (when receiving the product update package).
  3. Product testing. If the errors are found in the process of testing, the product release status is set to Invalid.
  • Operation.
  1. Putting the tested product into operation.
  2. The working database installation (when installing the product for the first time) or updating (when receiving the product update package).

Main Stages of Product Lifecycle for Developer

  • Interaction between Developer and Vendor.
  1. Receiving the product distribution kit from the vendor. The further stages are made within the developer organization.
  2. Loading the distribution kit to the repository.
  1. Putting the product distribution kit into development to perform integration and modification.
  2. Installing or updating the database that will be used to start the software product in the course of development.
  3. Development. The development is performed within one of the development branches, in one or several programming layers.
  4. The product release issue after finishing the development stage and preliminary testing.
  • Testing.
  1. Putting the product release into testing.
  2. The test database installation or updating (if necessary).
  3. The product testing. If the errors are found in the process of testing, the product release status is set to Invalid and release is reworked .
  • Operation. This stage is applicable for the developer who operates the product themselves.
  1. Putting the tested product into operation.
  2. The working database installation or updating (if necessary).
  • Distribution. This stage is included into the product life cycle if vendor plans to deliver the developed product to one or more their own customers.
  1. Preparing the product distribution kit for the customer (or for several customers). The distribution kit comprises only those units that must be delivered to this particular customer. Moreover, the distribution kit can contain the source codes of the part (or all the parts) from these units.
  2. Creating the software product initial installation package or update package to be delivered to the customer on basis of the prepared distribution kit (for details, refer to Creating Update Package for Customer).
  3. Delivering the distribution kit to the customer.

For details on testing and operation stages, refer to RadixWare. Software Products Installation and Upgrade Technology.

Project Structure

A project has a tree-like structure composed of the following elements: branches, directories, files. The project tree contains the following branches:

Tree Branch Icon Description
<Project Title> User interface 4.jpg Main project branch
Config User interface 12.jpg Settings branch. The branch contains the repository general settings.
Distribution kits User interface 7.jpg Distribution kits branch. The branch contains the software product distribution kits received from the vendor.
Scripts User interface 9.jpg Scripts branch. The branch contains the scripts for:
  • primary installation of all software product layers
  • installation of software product versions for all layers
Development User interface 6.jpg Development branch. The branch contains the software product files distributed by development subbranches. The branch is used by the vendor.
Releases User interface 8.jpg Releases branch. The branch contains the software product releases. The branch is used by the vendor.
Customers User interface 5.jpg Customers branch. The branch contains subdirectories with the software product distribution kits for customers (separately for each customer). The branch is used by the vendor.
Test User interface 10.jpg Testing branch. The branch contains the software product test files. The branch is used during the software product testing.
'Production User interface 11.jpg Production branch. The branch contains the software product production files. The branch is used when the product is in production.
Archive User interface 3.jpg Archive branch. The branch contains the software product releases and distribution kits, scripts relating to the outdated software product versions.
Note.jpgThe section describes the structure of project branches that are present in the tree only if the customer makes own developments (these branches are also used by the vendor):
  • Development
  • Releases
  • Customers
  • Archive

For the detailed description of other branches, refer to RadixWare. Software Products Installation and Upgrade Technology.

The description of each project branch and the list of available specific commands for each navigation tree item are provided below.

Note.jpgThe commands marked with "*" (asterisk) are described in theRadixWare. Software Products Installation and Upgrade Technology.

Distribution Kits Branch

The following table describes the context menu specific commands available in the Distribution Kits branch and its directories if the project is set up for development:

Name Contextual Menu Specific Commands
Distribution Kits

Absent

<Product>

Absent

<Distribution Kit>
  • *Install to Database. Installs the database from the current distribution kit.
  • *Update in Database. Updates the database up to the current distribution kit.
  • Send to Development. Sends the distribution kit to development. For details, refer to Development Start.
Scripts

The following commands are available for the software product layer branches:

  • Create Empty Upgrade Package
  • Save Scripts to File
Release

Absent

Properties

Absent

Scripts Branch

The following table describes the context menu specific commands available in the Scripts branch and its directories if the project is set up for development:

Name Contextual Menu Specific Commands
Scripts

Absent

<Layer>
  • Save Scripts To File. Saves the scripts of upgrade from the previous software product release to a new one in SQL file. The command is performed for the current layer. At that, the dialog box is displayed where it is required to specify the source and target release versions in the Source Release and Target Release parameters respectively.
  • Create Empty Upgrade Package. Creates an empty package of the scripts of upgrade from the previous software product release to a new one. When the command is performed, the dialog box is displayed where it is required to specify the source and target release version in the Source Release and Target Release parameters respectively.
<Ri - Rj> - scripts package
  • Create New Script. Creates a script in the current package.
  • Delete. Deletes the script package.
  • Create Downgrade Scripts
<script>.sql

Delete. Deletes the script from the package.

Note.jpgFor details on specific commands of the scripts branch, refer to Script Packages.


Development Branch

Dev branch.jpg

Example of directories structure in the Development branch

The branch has the following structure:

Development/
<Branch>/
<Layer>

The following table describes the directories, files and contextual menu commands of the Development branch:

Name Description Contextual Menu Specific Commands
Development Development branch.

Absent

<Branch*> Software product development subbranch (main, offshoot or additional).

*<Branch> - branch name.

  • Fork. Creates an additional development branch.
  • *Export XSD Schemas
  • *Export HTML Documentation
  • *Analysis of API Compatibility
  • *Analysis of System Changes
  • *Layers Information
  • Delete. Deletes the development branch. The command is not available for the trunk branch.
<Layer*> The directory containing the scripts for a certain software product layer (<Layer>).

*<Layer> - software product layer name.

Absent

Releases Branch

Release branch.jpg

Example of directories structure in the Releases branch

The branch has the following structure:

Releases/
<Release>/
<Layer>


The following table describes the directories, files and contextual menu commands of the Releases branch:

Name Description Contextual Menu Specific Commands
Releases The releases branch.

Version Status Information. Views the information on software product release statuses.

<Release*> The software product release directory.

*<Release> - software product release identification number.

  • *Build | <Test> Environment
  • *Build | Production Environment
  • *Configure
  • *Install to Database. Installs the database for the current release version.
  • *Update in Database. Updates the database up to the current release version.
  • Create Offshoot. Creates the offshoot development branch on basis of the current release.
  • Used by Customers.
  • Send to Archive. Sends the release to archive.
  • *Export XSD Schemas
  • *Export HTML Documentation
  • *Analysis of API Compatibility
  • *Analysis of System Changes
  • *Generate Create User Script
  • *Generate Product Installation Script
  • *Layers Information
  • Delete. Deletes the release directory.
<Layer> The directory containing the software product files distributed between the software product layers (<Layer>).

*<Layer> - the software product layer name

*Show License

Customers Branch

Customers branch.jpg

Example of directories structure in the Customers branch

The branch has the following structure:

Customers/
<Customer>/
Databases
<Distribution Kits>
<Distribution Kit>/
Logs
Notification
Properties

The following table describes the directories, files and contextual menu commands of the Customers branch:

Name Description Contextual Menu Specific Commands
Customers The customers branch.
<Customer*> The customer directory.

*<Customer> - customer name.

  • Configure. Opens the customer description editor.
  • Send to Archive. Sends the customer to archive.
  • Load Update Logs. Loads the update log received from the customer.
  • Delete. Deletes the customer.
Databases The database access parameters editor.

The editor is identical to the database access parameters editor in the project settings. For details, refer to RadixWare. Software Products Installation and Upgrade Technology / Setting up Database Access Parameters.

Configure. Opens the database access parameters editor.
<Distribution Kits> The directory contains the software product distribution kits prepared for the customer. The distribution kits are sorted by batch number in the descending order. Create New Distribution Kit. Prepares the distribution kit for customer.
<Distribution Kit*> The distribution kit directory.

**<Distribution Kit> - software product distribution kit number in the format <N - D>, where N - package sequence number D - distribution kit number composed of the release number (f.f.f.f) and optionally distribution kit version (V)

  • Configure. Opens the distribution kit properties editor.
  • Create Update Package. Creates update package for customer.
  • *Install to Database. Installs the database for the customer distribution kit.
  • *Update in Database. Updates the database to the version of customer distribution kit.
  • *Analysis of API Compatibility
  • *Analysis of System Changes
  • *Generate Create User Script
  • *Generate Product Installation Script
  • *Layers Information
  • Delete. Deletes the distribution kit.
Logs The update log files received from the customer. Load Update Logs. Loads the update log received from the customer.
Notification The notification service editor for the current customer.

The editor is identical to the notification service editor in the project settings. For details, refer to RadixWare. Software Products Installation and Upgrade Technology / Setting up Notification Service Parameters.

Configure. Opens the notification service editor for the current customer.
Properties Depending on the location contains one of the following editors: Configure

Archive Branch

Archive branch.jpg

Example of directories structure in the Archive branch

The branch has the following structure:

Archive/
Customers/
<Customer>
Releases/
<Release>
Scripts/
<Layer>

The following table describes the directories, files and contextual menu commands of the Archive branch:

Name Description Contextual Menu Specific Commands
Archive The archive branch. Absent
Customers The directory contains the list of customers moved to the archive.

Customer Distribution Kits. Views the versions of customer distribution kits.

<Customer*> The archive customer directory.

*<Customer> - customer name.

  • Restore from Archive. Restore the customer to archive.
  • Delete. Deletes the customer.
<Distribution Kits> List of customer distribution kits moved to the archive Absent
<Distribution Kit*> The customer distribution kit directory.

**<Distribution Kit> - software product distribution kit number in the format <N - D>, where N - package sequence number D - distribution kit number composed of the release number (f.f.f.f) and optionally distribution kit version (V)

  • Configure
  • Create Update Package. Creates update package for customer.
  • *Export Starter.
  • *Export Web-App
  • *Analysis of API Compatibility
  • *Analysis of System Changes
  • *Generate Create User Script
  • *Generate Product Installation Script
  • *Layers Information
  • Delete. Deletes the distribution kit.
Releases The branch of releases moved to the archive. 'Version Status Information'. Views the information on software product release statuses.
<Release*> The software product release directory.

*<Release> - software product release identification number.

  • *Build | <Test> Environment.
  • *Build | Production Environment
  • *Configure
  • Restore from Archive. Restore the release from archive.
  • *Export XSD Schemas.
  • *Export HTML Documentation
  • *Analysis of API Compatibility
  • *Analysis of System Changes
  • *Generate Create User Script
  • *Generate Product Installation Script
  • *Layers Information
  • Delete. Deletes the release directory.
Scripts The branch of scripts moved to the archive. Absent

Development Procedure

The product is developed by means of both RadixWare Designer and RadixWare Manager.

The development can be performed in one of the development branches:

  • The main development branch — trunk.
  • The additional development branches; they are used to develop the product versions that include the layers of the customer modifications.
  • Offshoot branches; they are used to make changes to the issued product release.

In the general case, the development procedure is as follows:

  1. Create the branch for development using RadixWare Manager (refer to Additional Development Branches, Offshoot Branches).
  2. Receive the working copy of the newly created development branch using RadixWare Manager (refer to Receiving Working Copy).
  3. In the created directory, start RadixWare Designer and with its help make the required changes in the application logic and / or the database structure.
  4. Install/update DB
  5. In RadixWare Designer, perform the Make Release procedure. At that, all layers from the development directory are included in the release being issued.
  6. Using RadixWare Manager, it is possible to transfer the performed changes in other branches or create the distribution kit for the customer (refer to Preparing Distribution Kit for Customer).

Development Start

To start the product development beginning from one of the available distribution kits (displayed in the Distribution Kits | <Product> branch of the project tree) received from the vendor, perform as follows:

1. Set up own repository by means of RadixWare Manager to perform own development. For this purpose, open the Config | Repository project branch and in the Base Development URI parameter, specify URI of the basic development layer. As a result, the project tree displays the branches prepared for development (the Development branch containing the main development branch - trunk).

2. In the context menu of distribution kit received from vendor, select the Send to Development item:

Send to dev.png

The opened Send Distribution Kit to Development dialog box contains the following parameters:

  • Select All Layers (SelectAllLayers.jpg button)/Unselect All Layers (UnselectAllLayers.jpg button) commands are used to select/unselect all distribution kit layers to be sent to development.
  • Check Binary Compatibility (CheckBinaryCompatibility.jpg button) command is used to check the binary compatibility of the development branch layers and layers that are sent to development from the distribution kit.
  • Source Distribution Kit. The distribution kit number sent to the development.
  • The left panel of the dialog box contains the list of the distribution kit layers sent to development. The list is presented as a table with the following parameters for each element:
    • Layer. The layer name and product release version that includes the latest update of this layer.
    • Send. If the flag is set, the current layer will be sent to development. By default, the flag is set for each layer.
  • Target Branch. The existing development branch where the distribution kit content will be sent to (by default, it is the trunk branch).
Example.jpgIf there are no development branches in the repository (for example, the trunk branch was deleted using the SVN client), when executing the Send to Development command, the trunk directory is created automatically.
  • The right panel of the dialog box contains the list of layers (with indication of the layer name and product release version that includes the latest update of this layer) present in the selected development branch.

After the command execution, the specified product layers received from vendor are copied from the distribution kit to the selected branch.

3. In the context menu of the Development | Trunk branch, select the Checkout item.

4. In the received directory, start RadixWare Designer and create the development layer. For this layer, specify URI mentioned in the 1st step and make the required changes.

Further, when a new distribution kit is received from the vendor, perform as follows:

1. Send the distribution kit to the development branch (refer to Send to Development command description). When executing the command, the software product layers (with the latest update) received from the vendor are copied to the selected branch. This does not affect the development layers. As a result, this branch contains the created product version that comprises both the updated layers received from vendor and user developments.

2. Select the Team | Update menu item in RadixWare Designer and perform the development.

Example.jpgLet the distribution kit received from vendor comprise the org.radixware and org.radixware.radinsk layer. Assume that the customer would like to perform their own developments in the org.radixware.radinsk.money layer based on org.radixware.radinsk. Then, the development will include the following steps:
  1. Receive the distribution kit from vendor.
  2. In the Base Development URI parameter of the repository editor (Config project branch | Repository), specify the URI of the basic development layer: org.radixware.radinsk.money.
  3. In the context menu of the received distribution kit, select the Send to Development item and specify trunk as the target branch. At that, in the Development | trunk branch, two following layers appear: org.radixware and org.radixware.radinsk.
  4. In the context menu of the Development | trunk branch, select the Checkout item.
  5. In the received directory, start RadixWare Designer and create the org.radixware.radinsk.money layer in which the required changes must be made. This layer is created in the Development | trunk branch.
  6. At receiving the notification from vendor about a new distribution kit issue, receive the latter from vendor.
  7. Execute the Send to Development command. At that, all three layers remain in the Development | trunk branch.
  8. In RadixWare Designer, select the Team | Update menu item and continue the development.

If the distribution kit received from vendor contains the development layer, but the installed distribution kit does not contain such a layer, it is required to edit the set of layers of the current product directory prior to installing a new distribution kit. For this purpose, execute the Configure Distribution Kit Layers command in the product directory context menu (Distribution Kits branch | <Product>).

Receiving Working Copy

To start RadixWare Designer and work on one of the development branches, receive the working copy of this branch. For this purpose, select the Checkout menu from the context menu of the respective development branch in the project tree. At that, the system offers to specify the directory for receiving the working copy. To receive the last branch revision from the repository, select the Team | Update menu item in RadixWare Designer.

Additional Development Branches

To create the additional development branch, select the Fork item from the context menu of existing branch in the project tree. At that, the user is asked to specify the name of the branch to be created. As a result the selected branch copy is created (in the same way as the svn copy command).

Offshoot Development Branches

The offshoot branch is created to perform the essential release modification. To start development of such branch, select the Create Offshoot item in the release context menu of the project tree. At that, the release is copied to the new branch which will be available in the Development project branch.

Creating Release by Offshoot Branch Having made the required changes in the created development branch in RadixWare Designer, create the release (refer to RadixWare. Programming Guide). As a result, the created release will appear in the Releases branch of the RadixWare Manager project tree.

Creating Update Package by Offshoot Branch To deliver the created release to the customer, create the update package for the latter (refer to Creating Update Package for Customer). At that, the update package is created. As compared with the release, it contains only the added and modified files.

Installing/Updating DB for Development

In the course of development, it is possible to start the software product in the development mode in order to check the result or test the modifications. The connection to DB must be present to start the software product in the development mode. Thus, it is required to install the DB or update the existing one. For this purpose, execute the Install to Database or Update in Database command in the context menu of the distribution kit last sent to development (for details on installing and updating DB, refer to RadixWare. Software Products Installation and Upgrade Technology). For details on how to start the software product in the development mode, refer to RadixWare. Programmer Guide / Starting RadixWare Server and RadixWare Explorer in Development Mode

Release Status Management

Each product release has its own status. The following release statuses are available:

  • New. A new release created using the RadixWare Designer.
  • Test. The release is testing.
  • Urgent. The release must be delivered to the customer as soon as possible before the testing is complete.
  • Production. The release is ready for commercial operation.
  • Invalid. The errors are found in the release, it must not be used anymore.
  • Expired. The release support date came to an end; the release must not be used anymore.

To change the release status, use release editor, refer to Release Editor.

The initial release status is New (it is set to the release automatically at creation). The Test status indicates that the release is being tested. Having being tested, the release status is set to Production and it can be put into operation and delivered to customers. If errors are found when testing, the release status is set to Invalid. If the release contains the corrections that must be urgently delivered to the customer, the release status is changed from New or Test to Urgent. The releases with this status can be delivered to the customer before the testing is complete and without changes description. If the errors are found when operating Production, the release status is set to Invalid. After that, putting this release into operation and delivering it to the customers is blocked. The release status can be changed to Expired when its support date came to an end. When the release status is changed, all the parties concerned receive notifications via email. When putting the release into operation or testing, the notification is performed either.

Viewing Release Statuses

To view statuses of all issued releases, use the Releases branch. The branch editor displays the table containing the following columns:

  • No. The release ordinal number.
  • Release. The release version.
  • Status. The release status (the Status parameter value in the release editor, refer to Release Editor).

Release Editor

To open the release editor, double-click on the release branch in the project tree. The release editor overview looks as follows:

Release-editor.jpg

The release editor contains the following parameters:

  • Release Number. The release number. The parameter is not editable.
  • Status. The release status.
  • Source Branch. The name of development branch on which the release was created. The parameter is not editable.
  • Repository Revision. The revision number of SVN repository on which the release was created.
  • Previous Release. The previous release number.

The Generate Developers Descriptions button creates the release description draft from the comments to SVN revisions. The Send Notification ’Release Created’ button sends notifications via email about release issue to the parties concerned. The button is not available if notifications are not set up for the project. For the notification settings, refer to RadixWare. Software Products Installation and Upgrade Technology.

The release description editor comprising the editors with description of changes grouped by layers is given below. The first group contains the editors with description of changes for the layers to be delivered to the customers. The By Developers field is displayed for every layer; one field is displayed for every language supported by the layer. To open the field editor click on the field or click Edit-small.jpg next to it. The By Developers field defines the description of changes in release provided by developers. This field is filled automatically when clicking the Generate Developers Descriptions button. In other fields, the description of changes is translated respective languages. Copy-small.jpg and Paste-small.jpg buttons next to the fields enable to copy the field contents to the clipboard and insert the clipboard contents into the field respectively. When saving the changes in the release editor, the system checks whether there are changes made by other users. If there are any changes, the user is suggested to save his own changes (and overwrite the changes made by other users) or cancel saving of his changes:

Release changed another user.jpg

Description Editor The description editor looks as follows:

Changes editor.jpg

The description editor contains a toolbar and a table with rows each of those describes the change. The table contains the following columns:

  • Type. The type of change. Available options:
    • Not defined
    • Major improvement
    • Minor improvement
    • Change
    • Deletion
    • Bug fix
  • Issue. The information about the internal issue to perform changes.
  • Component. The product component with changes.
  • Commit message. The description of change.

Edit.jpg is used to edit the description of change using modal selector. The table below describes the toolbar buttons of description editor:

Button Name Description
Plus.jpg Add Record Adds a row in the table of changes
Delete.jpg Remove Selected Records Deletes the selected rows from the table of changes
Delete-all.jpg Remove All Records Deletes all rows from the table of changes
Arrow-up.jpg Move Up Selected Records Moves the selected table rows one level up.
Arrow-down.jpg Move Down Selected Records Moves the selected table rows one level down.
Sort.jpg Sort by Type Sorts the table rows by the type of changes
But save.jpg Save ALL Changes to Editor Saves all changes performed in the release editor
Export to XML.jpg Export to XML Exports the changes description to XML file
Import from XML.jpg Import from XML Imports the changes description from XML file
Export to TXT.jpg Export to TXT Exports the changes description to TXT file
Import from TXT.jpg Try Import from TXT Exports the changes description from TXT file.

A separator is used for columns in the file being imported. The rows in the file must comply with the following format: [Type] (Issue) Component. Description, where Type is defined according to the used system of conventions:

  • [] - Not defined
  • [++] - Major improvement
  • [+] - Minor improvement
  • [*] - Change
  • [-] - Deletion
  • [#] - Bug fix
  • [ii] - Internal improvement
  • [ib] - Internal bug fix

Script Packages

Script package is a set of SQL scripts enabling to update the database structure when updating to a new product release. Script package is described by the initial and target releases.

Note.jpgDuring the usual updating procedure and product support, the database scripts are set automatically by RadixWare Designer and there is no need to change or create them manually. However, in some exceptional cases it might be necessary.

To create a script package, select the Create New Scripts Packet item from the context menu of the Scripts project branch. At that, the system requires the versions of initial and target releases. It is possible to specify "x" as a release version. Such script packages can be used when updating from (or to) any release.

To create a script, select the Create New Script item from context menu of the branch of database type ("oracle") which is a child one of the script package branch in the project tree.

To remove the script from the package, select the Delete item from the context menu in the project tree. At that, the system requests to confirm the action. Each script package can have the description of the changes performed by it. To edit this description, select the Edit Change Description item from the branch context menu of database type in the project tree.

Archive

To facilitate the project management at having a large number of releases, RadixWare Manager supports the releases archive. Releases, customers, customer distribution kits and scripts of outdated product versions can be stored in the archive. When archiving, the objects are transferred to the Archive project branch.

When archiving a release, all the previous (older) releases and all the customer distribution kits relevant to these releases are archived either. Moreover, the scripts used for upgrading to or from any archiving releases.

At restoring the release from the archive, all the following (newer) releases located in the archive and all the customer distribution kits relevant to these releases are recovered either.

When archiving the customer, all customer distribution kits are archived as well. To send the release/customer to archive, select the Send to Archive item from the release/customer context menu in the project tree. At that:

  • If the release is archived, the dialog box is opened that displays all releases, distribution kits and scripts to be archived. To confirm the operation, click the Send to Archive button.
  • If the customer is archived, the dialog box is opened to enter the reason of sending the customer to archive. The dialog box looks as follows:

Send to Archive comment.png

To restore the release/customer from archive, select the Restore from Archive item from the release/customer branch context menu in the Archive branch. At that:

  • If the release is restored from the archive, the dialog box is opened that displays all releases, distribution kits and scripts to be restored from the archive. To confirm the operation, click the Restore from Archive button.
  • If the customer is restored from the archive, the dialog box is opened to enter the reason of restoring the customer from the archive.

Customer Support Procedures

Customer support using RadixWare Manager in the general case includes the following steps:

  1. Create the customer description (refer to Customer description management).
  2. For the created customer, prepare a distribution kit based on one of the issued product releases (refer to Preparing Distribution Kit for Customer). It is possible to prepare the software distribution kit for several customers simultaneously (refer to Preparing Distribution Kits for Several Customers).
  3. Create the update package based on the created distribution kit (refer to Creating Update Package for Customer).
Note.jpgThe actions described above in items 2 and 3 can be performed in GUI application of RadixWare Manager application and in its console version as well (for details, refer to Commands of RadixWare Manager Console Application).

Once the software product was installed on the customer side (in a test mode or in commercial use), it might be necessary to receive the update log from the customer.

Customer Description Management

To manage customer descriptions, use the Customers branch in the project tree. To add the customer description, select the Create New Customer item from the Customers branch context menu of the project tree (see below). To edit the customer settings, use the Properties child branch of the customer branch in the project tree. The Customer description editor contains the General and Modules pages.

"General" Page

  • Title. The customer name. The parameter is mandatory.
  • Customer URI. The unique customer identifier. It is editable only when creating a customer description.
  • Distribution Kit URI. URI of the upper layer of the software product delivered to the customer.
  • Languages. The list of languages that descriptions of changes in distribution kits delivered to the customer must be translated into. When building the distribution kit without descriptions of changes translated into all specified in this parameter languages, the systems displays a warning.
  • Status. The customer status. Available values: Test, Prod.
  • Distribution Kit on Test. The distribution kit tested by the customer.
  • Distribution Kit on Production. The distribution kit used by this customer in production.
  • Include ALL Issues in Upgrade Description. If the flag is set, the update descriptions delivered to the current customer will contain the changes of all projects. If the flag is not set, the descriptions will contain only changes of the projects specified in the Issue Tracking Project parameter.
  • Issue Tracking Project. The project identifiers used in the task and project management system. The changes performed within these projects will be included in the update descriptions delivered to the current customer. The parameter values are separated by comma. The parameter is available if the Include ALL Issues in Upgrade Description flag is not set.
Note.jpgIf the Issue Tracking Project parameter is not defined and the Include ALL Issues in Upgrade Description flag is not set, the customer will receive only the description of issues without numbers assigned in the task management system.
  • Notify Internal Changes. If the flag is set, the update descriptions delivered to the current customer will contain the information on internal changes (the changes with Internal improvement or Internal bugfix status).
  • Product Prefix. The prefix added to the customer software product name. The prefix is added in the beginning of the Title field in the layer.xml file for the software product upper layer (for example, files\org.radixware.radinsk\layer.xml) and in the customer notification on the built distribution kit (if the notification service is set up for the current customer).
  • Notes. The comment on customer description.

"Modules" Page

The page is used to set up the layers and units that will be delivered to the current customer. The page contains the following elements:

  • Release. The software product release containing the list of units that can be delivered to the current customer. The value is selected from the list of software product releases, by default, the latest release is displayed in the editor.
  • Export Modules to File (Export 1.jpg button) and Import Modules from File (Import 1.jpg button) commands are used to export from/import to XML file the list of units delivered to the customer.
Note.jpgThe list of units can be changed in the new software product releases. Thus, prior to exporting the list of units previously imported, it is recommended to compare it with the list of units in the current release.
  • The list of all units included in the selected customer release. Opposite to each unit from the list, in the Give column, it is possible to specify the form of the unit to be included in the distribution kit. Possible values:
    • Bin. Include the compiled binary files.
    • Bin, Src. Include both compiled files and source codes.
    • None. Do not include the unit (section, layer) into the distribution kit.
    • Inherited. The value is inherited from the parent object (segment, layer).

The Result column value indicates whether the unit will be included in the update package. If the unit inherits the settings from the parent object (the Give column value is Inherited), the Result column contains the value specified for the parent object. When the unit is selected from the list, the This Module is Used by and This Module Uses pages of the Dependencies area display the list of unit dependencies:

  • Show All (Show all.jpg button). The toggle button with two modes: show all unit dependencies / show only dependencies of the unit itself.
Example.jpgCondition: unit1 is linked with unit2, unit2 is linked with unit3, unit3 is linked with unit4; unit1 is selected in the list of all units (in the left editor panel).

Result:

  • If the Show All button is on, the unit2, unit3 and unit4 will be displayed on the This Module is Used by page.
  • If the Show All button is off, the unit2 will be displayed on the This Module is Used by page.
  • Unfold the Upper Branch (UnfoldtheUpperBranch.jpg button). The button is used to unfold the upper level containing all unit dependencies. If the Show All button is on, all links of two units are displayed.

The units that will be delivered to the customer are marked in bold type in the list.

The example of the editor of the units to be included in the customer update package:

Customer modules.png

Viewing List of Customers Using Software Units

To view the list of customers that will receive the particular unit as a part of the distribution kit, perform as follows:

  1. In the project, open the Releases branch (or any other branch containing the list of software product units, for example, Distribution Kits | <Product>, Development, Customers | <Customer> | Distribution Kits, Test, Production), select the software product version and required layer.
  2. Select the layer unit and get the list of customers using this unit by means of the Module is Delivered context menu. The list of customers is displayed in the information dialog box and can be copied to the clipboard by means of the Copy to clipboard context menu.

Module is delivered.png

Viewing Versions of Customer Distribution Kits

In case the product is supported by many customers, it might be required to learn on-the-fly what product versions are installed on the customer side. For this purpose, either select the Customers Distribution Kits item from the context menu of the project tree root or double-click on the Customers project tree branch. At that, in the main part of RadixWare Manager dialog box, the page with the list of all customers will be displayed. The table contains the following parameters:

  • No. The record ordinal number.
  • Customer. The customer name.
  • Test Version. The version of the distribution kit tested by the customer (the Distribution Kit on Test parameter value of the customer description editor).
  • Product Version. The version of the distribution kit used by the customer in production. (the Distribution Kit on Production parameter value of the customer description editor).
  • Last Version. The version of the last distribution kit prepared for the customer.

Preparing Distribution Kit for Customer

To start creating distribution kit, select Create New Distribution Kit on the context menu of the Distribution Kits branch (the customer branch of the project tree). At that, the dialog box containing the following elements is invoked:

  • General page
  • Description page
  • Give Elements page
  • Changes page
  • Check binary compatibility after commit. If the flag is set, when creating a distribution kit, the application will check the software product layers of the previous distribution kit and distribution kit being created for binary compatibility. By default, the flag is not set. If the dialog box used to create a distribution kit is invoked not for the first time, the flag state is saved from the previous invocation.
  • Create update file. If the flag is set, the update package will be created on the basis of the created distribution kit. By default, the flag is set. If the dialog box used to prepare the distribution kit is invoked not for the first time, the flag state is saved from the previous invocation. The created update package usually requires to be signed. If the already set keys used for signing are absent, the user is asked to confirm creating of the unsigned update package.
  • Check. Click the button to preliminarily check if any errors can occur at the distribution kit creation. The check results are displayed in a separate dialog box.
  • Check and Process. Click the button to preliminarily check the distribution kit and create it if the check results do not contain any errors and warnings. The found errors and warning are displayed in a separate dialog box. If there are only warnings, the user is suggested to ignore them and create a distribution kit (the Yes button) or cancel the command execution (the No button). If there are errors, the user can cancel the command execution only.

It can take several minutes to create distribution kit.

Create distr.jpg

"General" Page

  • Customer. The customer description. The value is set automatically and then is not editable.
  • Customer URI. The value is set automatically and then is not editable.
  • Customer Status. The customer status. The value is set automatically and then is not editable.
  • Target Release. The release used to prepare the current distribution kit. The parameter value is selected from the list of releases located in the Release branch. By default, the last created release is used.
  • Variant. The variant of the created distribution kit. When creating the distribution kit repeatedly (if the distribution kit with the value specified in the Target Release parameter was already created), the value is set automatically. If the distribution is created for the first time, the default value is 0.
  • New Distribution Kit. The number of the distribution kit being created. The value is set automatically. When editing the value, it is possible only to increase the value.
  • Previous Distribution Kit. The number of the previous distribution kit the new one will be based on. If the parameter value is <None>, the installation distribution kit will be created.
  • Previous Distribution Kit Search in Archive. If the flag is set, the list of previous distribution kits contains the distribution kits from the archive. The parameter is not editable if the project does not contain the Archive branch.
Note.jpgAt the attempt to create a distribution kit on the basis of the Test release for the customer with the Prod status, the results of preliminary check (started by clicking the Check or Check and Process button) contain the respective warning.

"Description" Page
The page contains the editor used to describe the distribution kit being created. The editor consists of the toolbar and table containing the description of changes. The editor and release description editor are identical in their content and functioning. If the release does not contain the description of changes, the editor is not available.

"Give Elements" Page
The page contains the list of units that will be included in the distribution kit. The list is created automatically and consists of units set up in the customer description editor on the Modules page and units related to them.

Note.jpgIf the list of units in the distribution kit being created differs from the list in the previous distribution kit, the results of preliminary check (started by clicking the Check or Check and Process button) contain the respective warning.

"Changes" Page
The page contains:

  • the Files and Scripts pages displaying the added/modified files and scripts respectively
  • the Show auxillary files (api.xml, definitions.xml, directory.xml, directory-layer.xml, layer.xml, usages.xml) flag. If the flag is set, the list defined on the Files page will include the modified service files.
Note.jpgIt can take considerable time to create a list of modified files and scripts. As such, when opening the Changes page, the user is asked to confirm creating a list.


Preparing Distribution Kits for Several Customers

RadixWare Manager allows to prepare a distribution kit based on one of the product releases for several or all customers. For this, select Create Distribution Kits on the context menu of the Customers branch. The system opens the dialog box used to define the command settings:

Create distr kits.jpg

The Target Release parameter specifies the release used to create the distribution kits for selected customers. The parameter value is selected from the list of releases located in the Release branch. By default, the last created release is used. The list of customers contains the following information on each customer:

  • Customer. The customer name and status.
  • Prior Distribution Kit. The number of the previous distribution kit the new one will be based on. The value is set automatically depending on the Prior distribution kit search mode parameter value:
    • Distribution kit with version not more than release version. The last created distribution kit whose version is not more than the release version specified in the Target Release parameter. The default value.
    • Last distribution kit created for this customer.
    • None (Installation distribution kit). The installation distribution kits will be created for the selected customers.
  • Process. The flag indicates whether to create a distribution kit for a customer. It is possible to set/unset this flag for each customer manually or use the following menu items in the upper panel to set the flag for a group of customers:
    • All. The flag is set for all customers.
    • Test. The flag is set only for customers with Test status.
    • Prod. The flag is set only for customers with Prod status.
    • None. The flag is unset for all customers.

The dialog box contains the following flags:

  • Check binary compatibility after commit. If the flag is set, when creating distribution kits, the application will check the software product layers of the previous distribution kit and distribution kit being created for binary compatibility. By default, the flag is set.
  • Create update file. If the flag is set, the update packages will be created on the basis of the created distribution kits. By default, the flag is set. The created update package usually requires to be signed. If the already set keys used for signing are absent, the user is asked to confirm creating of the unsigned update package.

Click the Check button to preliminarily check if any errors can occur at the distribution kit creation. The check results are displayed in a separate dialog box.

Click the Check and Process button to preliminarily check the distribution kits and create them subsequently if the check results do not contain any errors and warnings. The found errors and warning are displayed in a separate dialog box. If there are only warnings, the user is suggested to ignore them and create a distribution kit (the Yes button) or cancel the command execution (the No button). If there are errors, the user can cancel the command execution only.

It can take several minutes to create distribution kits.

Viewing Distribution Kit Properties

To open the customer distribution kit editor, double-click the distribution kit branch in the project tree. The distribution kit editor contains the General and Given Elements pages.

The General page contains the following parameters:

  • Distribution kit number. The distribution kit identification number. The parameter is not editable.
  • Release status. The status of release on basis of which the distribution kit is created. The value is set automatically at the distribution kit creation.
  • Creation time. The date and time of the distribution kit creation. The parameter is not editable.
  • Previous distribution kit. The number of the previous distribution kit. The parameter is not editable.
  • Description. The description of the distribution kit.
  • Changes list. The area used to edit the descriptions of changes included in the distribution kit. The area contains a toolbar and a table with rows each of those describes the change. The changes description editor and release description editor are identical in their content and functioning.

The Given Elements page displays the software product layers, segments and units contained in the distribution kit as a tree. The Give column displays the form in which the objects are included in the distribution kit (Bin, Src or Bin, Src).

The editor looks as follows:

Customer distrib editor.png

Creating Update Package for Customer

To create the update package, select the Create Update Package item from the distribution kit context menu in the project tree. It is also possible to create the update batch by selecting the respective item on the context menu of the distribution kit located in the Archive branch. Executing the command will open the Create Update Package dialog box for selecting the type of the update package to be created. The dialog box contains the following options:

  • Create installation distribution kit. Creates a package for installing the software product.
  • Create update from <version>. Creates an update package starting from the last distribution kit used by the customer. The option is available if distribution kits have been previously sent to the customer.
  • Create update from. Creates an update package from one of the distribution kits that has been previously sent to the customer. When selecting this option, the additional parameter becomes active. This parameter is used to select the distribution kit. The option is available if more than one distribution kit has been previously sent to the customer.

After the update package creation, the system will offer to sign the created zip file. The Output panel displays the path to the created file.

Commands of RadixWare Manager Console Application

The commands available for execution in the RadixWare Manager console version and list of arguments available for each command are presented in the table below:

Note.jpgFor the description of other commands available in the console version, refer to RadixWare. Software Product Installation and Upgrade/Working with RadixWare Manager Console Application/List of Application Commands.
Command Description Arguments Examples
CMD_CREATE_DISTRIB Creates the distribution kits for a customer/customers.

The list of customers can be defined automatically (depending on the selected mode) or specified in the CUSTOMER argument (if the PROCESS_SELECTED_CUSTOMERS mode is selected). The previous distribution kit used to create a new one can be defined automatically (depending on the selected mode) or specified in the PRIOR_DISTRIB argument for each customer (if the PRIOR_DISTRIB_SELECT mode is selected). By default, the update packages are created for the distribution kits when executing this command. To disable the update package creation, use the DISABLE_CREATE_UPGRADE_FILE argument.

Mandatory arguments:
  • PROJECT_DIR
  • SOURCE_RELEASE_NAME
  • One of the following arguments:
  • PROCESS_ALL_CUSTOMERS
  • PROCESS_PROD_CUSTOMERS
  • PROCESS_TEST_CUSTOMERS
  • PROCESS_SELECTED_CUSTOMERS and CUSTOMER
  • One of the following arguments:
  • PRIOR_DISTRIB_CREATE_MAX_NUMBER
  • PRIOR_DISTRIB_CREATE_LAST
  • PRIOR_DISTRIB_CREATE_ZERO
  • PRIOR_DISTRIB_SELECT and PRIOR_DISTRIB
  • ENABLE_CHECK_BINARY_COMPATIBILITY
  • DISABLE_CREATE_UPGRADE_FILE

Optional arguments:

  • CONFIG_FILE
  • SVN_PWD
  • KEY_STORE_PWD
  • One of the following arguments:
  • QUESTION_YES_ALL
  • QUESTION_NO_ALL
  • LOCAL_LOG_DIR
CMD_CREATE_DISTRIB PROJECT_DIR=c:\ProjectDir

SOURCE_RELEASE_NAME=1.2.26.20.16 PROCESS_SELECTED_CUSTOMERS CUSTOMER=customer.testuri.org PRIOR_DISTRIB_SELECT PRIOR_DISTRIB=867-1.2.25.10.1

If the distribution kits are created for several customers, and a different previous distribution kit must be specified for each customer, the command can be presented as follows: CMD_CREATE_DISTRIB PROJECT_DIR=c:\ProjectDir SOURCE_RELEASE_NAME=1.2.26.20.16 PROCESS_SELECTED_CUSTOMERS PRIOR_DISTRIB_SELECT CUSTOMER123=FirstCustomer PRIOR_DISTRIB123=PriorDistribForFirstCustomer CUSTOMER_abc=SecondCustomer PRIOR_DISTRIB_abc=PriorDistribForSecondCustomer CUSTOMER=ThirdCustomer PRIOR_DISTRIB=PriorDistribForThirdCustomer where the respective CUSTOMER and PRIOR_DISTRIB arguments have the identical postfix (it can be empty as well)

CMD_CREATE_UPGRADE Creates a distribution kit on basis of the customer distribution kit.

By default, the update package will be created for the distribution kit used to create the target distribution kit. To change this behavior, use the PRIOR_DISTRIB_CREATE_ZERO or PRIOR_DISTRIB argument (for details, refer to the argument

Mandatory arguments:
  • PROJECT_DIR
  • CUSTOMER
  • DISTRIB

Optional arguments:

  • One of the following arguments:
  • PRIOR_DISTRIB_CREATE_ZERO
  • PRIOR_DISTRIB
  • CONFIG_FILE
  • SVN_PWD
  • KEY_STORE_PWD
CMD_CREATE_UPGRADE PROJECT_DIR=c:\ProjectDir

CUSTOMER=customer.testuri.org DISTRIB=867-1.2.25.10.1


The arguments that can be used at command execution are presented in the table below:

Argument Description Examples
CONFIG_FILE Name of configuration file containing the command arguments. CONFIG_FILE=/home/testuser/RadixWareManagerProjects/config.conf
PROJECT_DIR Path to the project directory in the file system. PROJECT_DIR=c:\ProjectDir
SOURCE_RELEASE_NAME Number of software product release on basis of which the distribution kits are created. SOURCE_RELEASE_NAME=1.2.26.20.16
CUSTOMER URI of customer the command is executed for.

It can be used together with the PROCESS_SELECTED_CUSTOMERS argument.

CUSTOMER=customer.testuri.org
DISTRIB Name of distribution kit in the format: <N>-<f.f.f.f>v<V>, where

N - sequence number
f.f.f.f - release number
V - number of distribution kit version (can be absent)

DISTRIB=867-1.2.25.10.1
PROCESS_ALL_CUSTOMERS Creates the list of all customers.
PROCESS_PROD_CUSTOMERS Creates the list of customers with PROD status.
PROCESS_TEST_CUSTOMERS Creates the list of customers with TEST status.
PROCESS_SELECTED_CUSTOMERS Creates the list of customers that will be specified in the CUSTOMER argument.
PRIOR_DISTRIB_CREATE_MAX_NUMBER Selects the previous distribution kit with version not more than release version.
PRIOR_DISTRIB_CREATE_LAST Selects the last distribution kit created for the customer.
PRIOR_DISTRIB_CREATE_ZERO Selects the mode when the previous distribution kit is not defined. At that, the installation distribution kits/update packages are created (depending on the executed command CMD_CREATE_DISTRIB or CMD_CREATE_UPGRADE).
PRIOR_DISTRIB_SELECT Selects the previous distribution kit that will be specified in the PRIOR_DISTRIB argument
PRIOR_DISTRIB Name of previous distribution kit in format: <N>-<f.f.f.f>v<V>, where

N - sequence number
f.f.f.f - release number
V - number of distribution kit version (can be absent)

It can be used together with the PRIOR_DISTRIB_SELECT argument.

PRIOR_DISTRIB=867-1.2.25.10.1
ENABLE_CHECK_BINARY_COMPATIBILITY When executing the CMD_CREATE_DISTRIB command, check the binary compatibility of the software product layers of the created distribution kit.
DISABLE_CREATE_UPGRADE_FILE When executing the CMD_CREATE_DISTRIB command, do not update DB.
SVN_PWD Svn and ssh password to the repository. If the argument is absent, it will be requested from the user.
KEY_STORE_PWD Password to the keystore. If the argument is absent, it will be requested from the user.
QUESTION_YES_ALL Automatically answer with "yes" to all yes/no questions.

It cannot be used together with the QUESTION_NO_ALL argument.

QUESTION_NO_ALL Automatically answer with "no" to all yes/no questions.

It cannot be used together with the QUESTION_YES_ALL argument.

LOCAL_LOG_DIR Path to the directory where the log files are saved after the command execution. LOCAL_LOG_DIR=c:\RadixWareManager\logs

Update Package Digital Signature

To comply with the security requirements, RadixWare Manager supports the mechanism of protecting the product distribution kits, i.e. the digital signature (DS) of the update files for the product updates, patches and fixes.

To manage the set of keys and certificates in RadixWare Manager, the RadixWare Key Store Administrator application opened from the project parameters dialog box is used. For details on how to work with RadixWare Key Store Administrator, refer to RadixWare. Key Store Administrator. Administrator Guide.

Creating Package Digital Signature

When creating the update package for the distribution kit or the patch package for the patch, it is supposed that the zip file being created will be signed. If the key storage is not defined in the project at the package creation, the user will be asked to confirm the creation of the unsigned package.

To sign the packages, use the private key from the private key pair with the <URI>/upgrade/<N> alias where <URI> is URI of the product upper layer contained in the package, <N> is a key pair number.

Example.jpgTo sign the update package containing the updates for Radinsk (the org.radixware and org.radixware.radinsk layers), it is possible to use the private key from the key pair with the org.radixware.radinsk/upgrade/3 alias.

If the key storage contains several key pairs with the aliases of this type, the pair having the maximum number (<N>) will be used. If the key pair used to sign packages is compromised, it is required to generate or load another key pair and apply to it a similar alias whose number <N> is greater. Therefore, an actual key will be always used to sign packages.

When creating the signed package by means of the private key, DS of the package contents is calculated. This DS is placed into the package in the form of signature.sf file. The certificate (certificate.cer file) containing the respective public key is also included into the package.

If there is no key pair with the required alias in the key store at the moment of creating the package, the user will be asked to confirm creation of the unsigned package. Otherwise, the user is asked to enter the password for the key being used.

Verifying Package Digital Signature

When installing the initial installation package, update package or patch package, RadixWare Manager verifies DS of this package. To verify DS, the system uses the certificate contained in the package, in case the same certificate presents in the key store and marked as trusted. If such certificate does not present in the store or it is not marked as trusted, the warning will be displayed to the user.

The package with invalid DS can not be installed. In case the package is installed without DS, the user will be asked to confirm the action.