After a short description of D2000 V22 innovations in Part I , we bring you some more information focused mostly on:
D2000 tasks development and deployment
The creation of tasks in the D2000 application allows fast selection and deployment of a set of D2000 objects which have been modified during the resolution of a given task. This feature is especially useful in test and/or development instances of applications from which objects will be deployed into production application instance.
Information about objects changes is automatically written by the D2000 server into a separate database. This database is also used by the D2000 application layer for tasks management. Usage of issues database is enabled by application parameter IssuesDSN which is set to ODBC data source name for issues database.
After a user is logged in to any of the D2000 configuration processes (CNF, GR, HI), he is given a list of currently open issues from which he selects the one he wants to work on. After selection, all modified objects will be marked as a part of the selected issue.
The application layer allows management of issues such as creation, modification and deletion of issues. Issue Modification is primarily the change of its state and addition of comments and attachments. After creation, the issue is in “Open” state. When it’s been started to work on, it changes state to “In progress”. When it’s been resolved the state switches to “Done” and finally, when it’s been deployed to production, the state can be changed to “Closed”.
The user interface of the issue view shows all objects modified during the resolution of the issue and allows XML export of these objects. It also shows deleted objects. During the export of objects the user is notified if some of the objects have also been modified as a part of some other non-closed issue. Import of these objects might require additional modifications as they might use functionality that is not yet present in the production environment.
To identify conflicts when the imported object has also been modified in the production environment a simple versioning system has been implemented. The version number of the object is automatically increased when the object is saved in the production environment. The current object version number can be shown in the object list window in CNF.
Transfer of objects from production to test/development environment is realized by XML export or copy of the entire configuration database. Test environment must be marked by the application parameter TestVersion set to 1. In the test environment, version number stays the same when objects are saved. Consequently, when the object is transferred from the test to the production environment using XML import, version numbers of the existing and imported objects are compared. If they are the same import can be performed. If they are different import is not allowed until the conflict is resolved. Comparison of version numbers of objects can be disabled by turning on XML import parameter IGNR_VER.
