Greetings, fellow data analysts!

You certainly have seen files names with appendages such as “final v2” in your email inbox or on a server – names that reveal the authors’ premature hope that they would soon be moving on to other matters? Although packing the results of your work into files is convenient, files have the tendency to change and multiply like wild. With good organization, you can keep this problem under control. As the number of people who work with these files increases, however, many DeltaMaster clients prefer a technical alternative: Instead of distributing reports as files, they offer them through a central database known as Repository. This way, each application only exists once and they can control who can work exactly how with the application. Repository, therefore, is an important foundation for supplying information with DeltaMaster especially for larger or even enterprise solutions. This version of clicks! provides an brief overview – with no “v2” version to follow.

Best regards,
Your Bissantz & Company team

When you work with DeltaMaster, you can save your results in one of two ways: in files or databases.

Saving results in files is the older of the two options. Most DeltaMaster users have probably already worked with DAS files which contain Briefing Books along with their reports and analyses as well as all definitions, notations, settings, and so on.

As an alternative to files, you can also save all of these elements to a database or open them from a database also known as Repository. This has its advantages, especially when you want to deploy applications and reports that were created centrally to a large number of users.

On the following pages, we will provide an overview on working with Repository especially from the perspective of a report consumer. We will also compare this concept to saving results in files. For your IT experts, we will also briefly outline the system requirements and the installation process; detailed instructions are provided in a separate documentation.

Terminology

Repository is the central component for the database-driven deployment and administration of DeltaMaster applications. It also serves as the foundation for DeltaMaster WebOption, Add-in for Office, and DeltaMaster Gate. Repository is an administration database that is separate and independent from the database where the analysis data are stored. Instead of business attributes and measures, Repository stores DeltaMaster applications – the same information contained in a DAS file but in a database. Organizational information (e.g. permissions) is also stored in Repository.

Technically speaking, Repository consists of two components: a relational database where the applications, permissions, roles, etc. are stored, and a Windows service (“DeltaMaster Service”), which DeltaMaster uses to access the Repository database. This detail, however, is irrelevant for the purpose of this overview. The term Repository here refers to the service and database together. To interactively administer the objects in Repository, a further component called Repository GUI is available.

In DeltaMaster 5, the analytic results that you save are called an “analysis session”. When the analysis session is saved to a file, this is an “analysis file” (i.e. DAS or DM2GO file). When saved to a database, the analysis session is called an “application”. DeltaMaster 6 has simplified this terminology and always refers to “applications” regardless if they are stored in a file or in a Repository.

Opening and using applications

Opening applications from the Repository is simple. The Portal of DeltaMaster lists all known Repositories in a separate section (see screenshot on the previous page), each with a list of the related applications. If DeltaMaster does not display the section showing the Applications in Repository in the Portal, you must configure the Repository access for the DeltaMaster installation or the current user (see below for more information about the configuration).

DeltaMaster accesses the list of applications from the respective Repository where they are centrally maintained by the report editors. In doing so, DeltaMaster takes into account which user is logged on to the system and only displays the applications which the user can access in the Portal. In the context menu of a Repository, you can refresh the list of applications. This is useful when someone publishes additional applications while you are working with DeltaMaster. DeltaMaster will then display these applications in the Portal without requiring a restart.

Compared to working with files, this way of accessing applications is much easier for everyone involved. Report viewers are spared the task of searching for files (and the agony of wondering which version is correct). Instead, they select them from the predefined applications in a centrally maintained directory. Report editors don’t have to worry about distributing applications. All authorized users can access them from Repository – instantly and in the same version. As a result, any changes to reports instantly take effect for all users, and you can even pull reports completely from circulation.

Once you have opened the application, it looks and reacts identically to analysis sessions from files. The functions, the options, the way you work with reports and analyses are not dependent on where you have opened the application. The only difference occurs during saving: There are no drives, folders, or file names in Repository. Contrary, the Repository contains mechanisms like rules and rights to manage, who can save which objects, that don’t exist for files.

Changing and saving applications

As a report consumer, you generally only open an application to read it – regardless if you are using Reader, Viewer, Pivotizer, Analyzer, or Miner modes. These user modes determine which interaction and editing possibilities exist within the application. If you can save them in Repository depends on if the application was opened for read or write access.

In order to save changes, you must first open the application by the options dialog (context menu of the application in the Portal).

In the Options dialog box, you select to open the application for exclusive write access. This option protects the applications in Repository: It coordinates the processing by preventing multiple authorized users from working on the same objects at the same time and overwriting each other’s results.

Accordingly, DeltaMaster only grants write access to one user. During this time, other users can only access the application in read-only mode. If you want exclusive write access, you must request it explicitly when opening the application. You cannot claim it retrospectively.

The commands to save in Repository are organized like those for files in the File menu. You can save applications that are already opened from Repository by using the shortcut Ctrl+S on your keyboard. Here, there is practically no difference to saving to a file.

When you save an application to Repository for the first time (e.g. because it is a brand-new application or because you want to publish an existing analysis file through Repository), DeltaMaster will prompt you to complete a few mandatory specifications. At the top of the dialog box, you select the Repo­si­tory where the application should be written (see DeltaMaster deltas! 5.6.0, feature #6). The Connection properties derive from this selection. FileID is the unique identification number of the application. In the case of a new application, it is better to let DeltaMaster select the FileID automatically. For more information about the ID, please read the DeltaMaster WebOption handbook. The Name of the application will be shown wherever you can access Repositoriess. With Repository GUI, you can change it anytime and add a description as well.

Administering rights

One interesting function of Repository is that you can assign permissions for applications and even individual reports and folders of the Briefing Book. This makes it possible to provide or prohibit access to selected reports or folders for certain users (or the roles in which they are grouped). Depending on which rights the person opening them has, the same application may appear to be larger or smaller in scope.

The administration of permissions is broken down into two components and accounts for the prevailing distribution of tasks between IT and business departments.

In Repository GUI, you can define which user can access which applications at all. Here you can also define the membership of users in roles.

Directly in DeltaMaster, you can maintain which folders and reports the users in a role can access within an application (Folder Rights or Report Rights in the respective context menu in the Briefing Book). You can also specify the Session Rights (File menu) or Briefing Book Rights (context menu or I want to menu in the Briefing Book).

For detailed information about administering applications and roles with Repository GUI, please read the DeltaMaster WebOption handbook. Further information about report and folder permissions is contained in DeltaMaster deltas! 5.4.9, feature #20.

Configuring access to Repository

In order to access one or more Repositories, DeltaMaster requires their “coordinates” – specifically, the names or IP addresses of the servers that offer a Repository service. DeltaMaster retrieves this information from Windows Registry in one of two ways. First, it can be imported automatically from a central authority (e.g. system administrators or IT). This way, the individual workstations can be set up so that all Repositories are known and available without requiring any work from the users.
Secondly, you can allow users to enter Repositories on their own. In this case, they would need to enter the necessary information with a DeltaMaster dialog box that is available under Options (Extras menu) on the Portal tab. The upper part of the dialog box lists the Repositories that were entered by the system administrators. Users can neither change nor remove these entries. In the bottom section, they can add further Repositories. Each Repository monitors that the applications offered to a given user correspond with his or her permissions. Entering a Repository in the options, therefore, does not mean that the user can automatically access all listed applications. These applications still must be activated for that particular user. For more information, see DeltaMaster deltas! 5.6.0, feature #8.

Repository and ReportServer

You may use applications in Repository as a source of jobs in ReportServer. Aside from that, you can also use ReportServer to automatically publish applications in Repository. This way, you can use the update and iteration options in ReportServer to automatically prepare a number of individual Briefing Books and publish them through Repository.

Comparing the concepts

You can build DeltaMaster solutions using file-based, database-driven, or hybrid approaches. In addition, you can also transfer analysis files to Repository or save applications from Repository as analysis files at any time. This gives DeltaMaster users the freedom to decide for themselves whether they want to build a new solution in Repository from the beginning or migrate them at a later time (e.g. as the number of users begins to grow, report usage needs stricter regulations, or application deployment requires rationalization).

The following table compares and contrasts various characteristics of file-based and database-driven approaches to deploying applications:

Both options have their advantages. You cannot really say that one is generally better than the other – only which one is better for your specific scenario.

What IT has to know

Installation and the initial configuration of Repository are generally tasks for IT professionals – primarily because these tasks require special permissions and not because they are particularly complicated. The complete system requirements are documented in a separate installation and configuration guide. The section below provides a brief summary.

Repository requires:

• Microsoft SQL Server (database module) for the Repository database
• Microsoft .NET 4 Framework for the Repository service

The installation also requires administrator rights

• On the operating system level to install the service
• On the database level to create the Repository database, configure its permissions, and modify the rights to the databases with the application data

Experienced administrators or application managers with the respective permissions should only need about half an hour for the installation and initial configuration – provided, of course, that the system requirements have been fulfilled. A setup program (MSI) is available (see DeltaMaster deltas! 5.6.0, feature #8). A detailed installation guide that explains the installation without a setup program is also available in English and German.

The Repository database and the respective service can run on either different servers or the same one. To test it, you only need a normal PC workstation or a laptop where you can run DeltaMaster (i.e. desktop client). All DeltaMaster modules with Repository support (i.e. desktop client, Report Server, Web Client, Add-in for Office, DeltaMaster Gate) can use the applications in Repository simultaneously and in the same form. In conjunction with the desktop client, the main processing load comes from calculating and displaying reports in the desktop client; this is the same as in file-based usage.

In most cases, you will probably want to make a central setting on the PC workstations where the users can access one or more Repositories. The “coordinates” of the Repositories must be disclosed to the client installations of DeltaMaster. DeltaMaster will search for them in the Windows Registry (see DeltaMaster deltas! 5.6.0, feature #8) so that they can be easily installed on the users’ computers using the typical mechanisms. In addition, users can also enter Repositories individually in a dialog box in DeltaMaster.