Operational Management

Day to day application and system management
A rich set of framework management functionality ensure a solid foundation for application and system maintenance. These include management, scheduling and monitoring of multitasking batch jobs, physical database storage management, application change amangement, in offline design environment and MSI Package Pre-configuration and rollout management.

• Database Maintenance
  Increasing database size combined with the need for on-the-fly creation of new database objects including triggers, tables and fields makes database management critical. Especielly management of storage location and configuration of both user-defined database objects as well as the internal database objects stored on the database server becomes essencial. All database objects, including user-defined, are described via metadata. An embedded administation service can be activated in order to physically relocate these objects. The importance of this cannot be exaggerated in cases where the database server is reconfigured, for instance, in connection with hardware upgrade. The relevant service is reading both the database’s own “repository” as well as the system’s “repository”. Together these metadata constitute the consolidated database configuration, which is open for interpretation and reconfiguration almost without required DBA intervention. The same service also enables the facility for migration from one database platform to another. In this way, all database objects, with or without including user data, can be exported in an universal format and recreated in a completely new database environment – either on a similar database platform or a different one. For instance, database migration from MS SQL to IBM DB2 UDB without reprogramming the application enabled transparently.
• Distributing and Monitoring Replicated Clients
  Application can be deployed online connected to the database as well as “Offline/Replicated”. When “Offline/Replicated” a local database is established that may be either a 1:1 replica of the master database or a carefully defined database section containing only the data that are relevant for the individual user, among other things based on the users security clearance. Offline/Replicated users are established by assigning queries that specify the replicated data set. Monitoring and continuous expansion and reduction of data set can subsequently be carried out from the master database.
• Batch Invocation
  Various services are configurable with regard to batch invocation. As a result it is possible to create standard internal services, which are also capable of activating DMAPI custom-logic. A wide variety of standard batch job administrative tasks are available including start, stop, scheduling with repetitive patterns, monitoring, logging, etc. In addition, batch jobs are configurable with regard to parallel and queue based execution as well as interrelated dependencies.
• Offline Design
  Production-, Test- and Development environments are separable in such a manner that all metadata, Parameters, API Event custom-logic and entity expansions are designed and tested in a separate development environment. The benefits are obvious as this enables a phased implementation process and ensures integrated quality control at every stage in the deplyment process. Also development environment can be established without data allowing vital confidential data to be excluded from test- and development environments. With this all employees without data related clearance are able to carry out development of the application. The system monitors all types of application expansions, for instance, database expansions constituted by new tables, fields, triggers or expansions constituted by “Parameter Collections” for management of queries, data import/export and data transformation. The embedded application version management makes it possible to operate with many different revisions of design modifications. Design modifications developed in the development environment are promoted to either the test- or production environments. This is done by either establishing a connection directly to the published metadata loading service or by distribution of a metadata design block (a file) to the relevant server or client. The system fully supports replicated offline clients, who automatically deploy the design changes, including database schema changes, without any type of user intervention.
• Dialog Manager Application Programming Interface (DMAPI)
  Besides responding to fixed and parameter controlled metadata, both the interactive as well as the batch-invoked services can be custom programmed. For each service is implemented “Event Hooks”, which activate the custom-logic of the external program. Event hooks can consume both internal and external services whether these are published in SOAP, Corba Components, J2EE, PowerBuilder Objects, or .Net Assemblies. Consequently, custom-logic is developed and tested with full support for debugging. Via the embedded “Source Control” “Check-In” is carried out, which stores both the compiled version as well as the source code in the Metadata Repository. With the automatic installation mechanism all the program extensions are distributed to all clients.
• Installation (Rollout)
  The installation program supports MSI (Microsoft Windows Installer). Besides supporting installation program industry standards, the program has embedded MSI configuration services. This facility enables configuration of the MSI package and distributes this to clients, for instance via Active Directory. Thus, the MSI packages contain all the necessary information about where the program is to be installed, which shortcuts must be installed and, maybe most importantly, all the communication parameters for various external servers, such as databases and application servers. As a result, the MSI package can be installed without any administrator or user intervention.
• Transparent Distribution of META Data
  A Dialog Manager application consists mostly of metadata. They describe how the various internal services must cooperate and respond. In cases where these metadata are comprised of program files or image files it is required that each of the relevant files are physically installed on each client. In the same way, this functionality is automated and fully transparent for both user and administrator. The metadata files are simply loaded into the database, where they are stored as binary objects from where they are distributed when the program needs them.
• Embedded Database Communication Programs
  It is not necessary to install any extra driver software etc. in order to communicate with e.g. Sybase, DB2, Oracle or MS SQL. The entire load of known compatibility- and version problems concerning database driver software is eliminated with this one step.
• ODBC Configuration
  For database communication Dialog Manager employs standard ODBC. The application server publishes an ODBC configuration service allowing all data source configuration tasks to be automatically and transparently attended to for both users and administrators. The ODBC data source, which is dynamically created locally, can also be exploited by external programs.
• Central Configuration of Database Server & Application Server Services
  Due to the fact that various service communication parameters are stored centrally and redundantly, it becomes possible to “move” or protocol reconfigure servers without having to physically visit each installation and locally adapt communication parameters. This is highly relevant when an application- or database server is specified to, for instance, “listen” to a different TCP/IP port or physically moved to a new machine/domain.