Can someone give me an overview of how variables are handled on Enterprise? >> I have the basic procedures of creating and localizing them, but I am >> lacking the information about why one needs to do this. > > Those variables map to the "Project Variables" (as they are called in Studio). > In short, those variables must be declared because each of them become > separate columns in the database. From Proc. Admin. you create them and then > the Engine adds new columns to one of its tables (that is, the DB structure > changes). Eduardo] Columns for Project Variables are added to the Engine PPROCINSTANCE and PPROCINSTEVENT tables. If in addition, the Project variable is qualified as "Dimension" or "Measure", these will be as well added to some tables in the BAM and DataMart Databases. Depending on the engine used at deployment time, the engine db tables that will be modified.
> Much like the Roles mapping, there's also a Variable's mapping. You declare > the variables in Process Administrator and when you publish/deploy a project > you "map" the Project's declared variables to those configured on your > Enterprise environment. The names do not need to match, but the types must be > compatible. [Eduardo] It may be worth mentioning here that when new variables are added, that the Engine DB User has enough permissions to enable the proper ALTER of the previously mentioned Engine Tables. Otherwise, the table will not be able to work correctly. In the event that the engine tables cannot be modified, a proper error with the alter SQL Statement will be printed in the Engine logs. This SQL statement can be provided to the DBA so that it is manually run and continue correctly. However, the ALTER permission should be quoted somewhere since it is of special interest to administrators and DBAs. In very restricted environments, they do not grant ALTER permissions to the Engine schema owner. > Important point: > * You can map variables from 2 (or more) different projects to a single > variable in Enterprise. There's no conflict (they re-use the same DB column, > but each instance has it's own value) > > * The variable as you define it in Proc Admin is just a place holder. The > actual meaning of the variable is given by each project. So, 2 (or more) > projects may map to the same variable, but each project can give that > variable a different meaning (whether this is a good idea or not is a > different question) [Eduardo] This should be consider to some extend best practices since it helps better utilize existing resources. Tables with too many fields tend to run slower. In addition, there is a limit as to HOW many columns can be defined in a Table. Oracle being the RDBMS vendor being the most generous (less than 1024 table columns).
Ideally, different projects should map to the same variable with similar semantics. But this is not necessarily true. These variables are usually filtered by the process that provides the context for their content. So if for some reason, you need to use the same physical Enterprise variable for 2 different project variables and different meaning BUT the same type, then it is legal to do the mapping. Usually this is done to avoid an unnecessary increase in the amount of columns since this produces a performance side effect.