Build and Update domains in RPAS

After receiving some emails about how to build a domain? Or how to update within the RPAS? So, Decided to talk about how to build and update any domain and understand what it’s necessary to do it what you can’t forget it.

Forget the schemas and indexes

The first point we need to remember is RPAS is a platform that manage and organize many activities and functionalities in a solution. Thus, many things are done without the need for intervention.

One of the big differences we have with the RPAS against a relational database is about database structures. In RPAS we don’t need to manage or define any  structures as tables, schemas, indexes and organization of the database; what do you mean?

This is it! If in a tradicional database, we need to create all schemas, tables and fields and keys etc .; within the RPAS, we can forget everything all this.

Build a domain

After we have a configuration ready and all hierarchies were generated, we can create the domain of a solution. To do this, we have to use one of the binaries RPAS, the rpasInstall.

The rpasInstall is responsible for creating and updating the configuration in a given solution. Its most common use is apply patches in a solution.

The rpasInstall has several arguments, some of them are very young (confess that even I haven’t used them!); let’s see how to use it:

rpasInstall Options (select only one):

-fullinstall

This argument is responsible for building a RPAS domain.

By using this argument -fullinstall, RPAS understands that the domain doesn’t exist and it needs to run certain operations such as creation arrays of hierarchies and controls.

-patchinstall

This argument is responsible for updating a RPAS domain.

By using this argument -patchinstall, RPAS understands that the domain already exists and it needs to generate a delta between actual and new configuration to validate what it is necessary to update.

-testinstall

This argument is responsible only for testing the configuration that will be applied / installed in a RPAS domain.

By using this argument -testinstall, RPAS understands that any changes won’t be applied/installed in the environment; only activity will be validate configuration without errors,

By using -fullinstall always used for building an environment. The binary will understand the need to create all domain data structures such as hierarchies and internal arrays of controls because they do not exist.

In last versions of RPAS (before 13.3), there was also a constraint when it had the need to change any hierarchy or dimension ever created, fortunately this has been changed in the new version.

By using -patchinstall we always focus to upgrade domain. We use to update certain details of measures, new rules and new groups of rules, new workbooks, etc.

Bu using -testinstall we always validate that the configuration is without errors to apply. This option can be used before using the -patchinstall to avoid mistakes during upgrade time..

Required arguments:

-cn

<Config Name>

Required

This argument is responsible for defining the Configuration name that will be applied.

The application name it was defined in ConfigTools to identify the project

-ch

<Config Home>

Required

This argument is responsible for defining the PATH where the configuration is located within the server.

When running rpasInstall, one of the first steps we have a validation of <Config Name> within the <Config Home> if there is any errors files.

-in

<Input Home>

Required

This argument is responsible for defining the PATH where the binary will find the hierarchies files responsible for creation domain.

This folder should contain a file for each hierarchy used by the configuration.

-log

<Log Name>

Required

This argument is responsible for defining the rpasInstall execution log file.

Optional or Dependent arguments:

-configdir

<Config Directory>

This argument is responsible for defining the PATH where we can find the globaldomainconfig.xml

By using globaldomainconfig.xml, the rpasInstall understands that all information about domains (paths, partitioning, etc.) are defined in this file.

We shall see more details about globaldomainconfig.xml.

This argument should not be used together with the “-dh”. They are opposed arguments.

-dh

<Domain Home>

This argument is responsible for defining the PATH where the domain will be created.

By setting the <Domain Home>, rpasInstall understands that all domain structures will be created in PATH
.
This argument should not be used together with the “-configdir”. They are opposed arguments.

-p

<Dim Name>

This argument is responsible for setting which dimension will be used to split the domains.

This argument is required when you want to work with Global and Local domains.

This argument should not be used together with the “-configdir”. They are opposed arguments.

-updatestyles

This argument is responsible for update all workbook styles in the domain; rpasInstall will remove all user styles and update based in the new configuration.

-rf

<Function Name>

This argument is responsible for registering a certain library functions that will be used by the domain.

It’s necessary repeat the argument for each library that you want to register the domain

-skipvalidation

This argument is responsible for skip some validation during the build or patch processes.

-verbose

This argument generates more information on the rpasInstall execution log

Let a few examples of how to use the -fullinstall

rpasInstall -fullinstall -cn $ConfigName -ch $ConfigHone -configdir $ConfigDir -in $InputHome -log $LogFile -rf $FunctionName

rpasInstall -fullinstall -cn $ConfigName -ch $ConfigHone -dh $DomainHome -p $Dimension -in $InputHome -log $LogFile -rf $FunctionName

Let a few examples of how to use the -patchinstall

rpasInstall -patchinstall -cn $ConfigName -ch $ConfigHone -configdir $ConfigDir -in $InputHome -log $LogFile

rpasInstall -patchinstall -cn $ConfigName -ch $ConfigHone -dh $DomainHome -p $Dimension -in $InputHome -log $LogFile -rf $FunctionName

Global Domain Config

When we need to create a domain is necessary to define how we’ll split the domains. It can be a Simple Domain or a Global Domain to manage multiple domains.

Everything depends the number of records we have in the hierarchies, especially in the LOC and PROD hierarchies.

The globaldomainconfig.xml has the all domain organization, as if we’ll work as Global Domain, dimension level we want to split the domains and paths of all domains.

So rpasInstall uses this information to know where it needs to create the domains or where any change will be applied.

The file format is standard for any RPAS application; Because that, it’s very commom find some scripts responsible to generate automatically the file and the RPAS Admin doesn’t need to worry about its maintenance.

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<rpas>

 <globaldomain>
  <path>$Global_Domain_Path</path>
  <partitiondim>$Dimension</partitiondim>

 <subdomain>
  <subpath>$Global_Domain_Path/ldom0</subpath>
  <subpositions>$DimensionID01, $DimensionID012</subpositions>
 </subdomain>

 <subdomain>
  <subpath>$Global_Domain_Path/ldom1</subpath>
  <subpositions>$DimensionID03</subpositions>
 </subdomain>

  </globaldomain>
 </rpas>

By using this way, you can have a domain with multiple dimensions to it. This can be interesting when we want to balance of domains volumes to run parallel processes during the batches

Tips and Important Information

  1. Whenever you are using a Function Library, use the argument “-rf $FunctionName” to run rpasInstall. This is important to avoid some link errors after multiple executions;
  2. The rpasInstall doesn’t generate any message in the terminal, so if you want to validate the results and understand what happened with some error, you should check the $logfile;
  3. If you has changed any workbook like insert new measure or profile, you must use -updatestyle; if you don’t do it, new style won’t be available to your users.

Leave a Reply

Your email address will not be published. Required fields are marked *