cancel
Showing results for 
Search instead for 
Did you mean: 
Walter.Koller
Level 11
Status: New

We are using 6.9 and more recent versions of BP might have different possibilities.

In 6.9 the configuration of Archiving is limited to specify a target directory. 

There is no option to define the preferred RR the archiving should run.

There is no option to specify the Windows account that should be used 

And there is no possibility to specify the date/time when automatic archiving should start.

This causes certain challenges in a multi RR, multi BP instance, multi Windows account environment.

.) The target directory is only set per RR. We have to set the directory on each RR to ensure the files are saved in the same directory.

Each BP instance / environment has to have its own target directory otherwise restore will very likely fail or will be wrong. When moving a RR from one environment to another environment also the local archiving directory has to be set manually local on the machine. 

.) Preferably, all archiving files should be saved in the same central location and not local on each RR. This can be achieved by having a network share mapped on all RR. 

Since we cannot know what user is currently logged on to a RR when archiving kicks in, all robot Windows accounts have to have the share mapped and have to have full access to those folders.

This rises security concerns as logs needed for audit purposes can be altered by anyone who happen to have access to robot Windows accounts.

.) There is no information and no check if the target directory is the correct one since there is no information that would uniquely and easily identify the environment. 

In case archiving was done to the wrong target directory, correcting the error needs huge amount of manual effort. (basically going through all directory tree as RR is at the very end of the structure:

- Year
- Month
- Day
- Process name
- Runtime Resource name

)

It is always much more difficult to configure something like archiving on workplaces as they tend to be more volatile than servers. The best solution would be to have archiving executed as part of the application server service.

But also the RR side way of archiving could be greatly improved by:

  • storing target directory not RR local but centrally in repository
  • being able to specify the RR that should be used 
  • being able to create schedules (intervals, start times, ...) to run archiving

Another general improvement would be to add environment information to the archiving folder / files. Either more like for informational purpose when connection name is used or some new information as not-changeable name for the BP instance / repository. (I will create another idea for this identifier)