Multiple Configuration Files

If multiple developers edit the same cfg.factory file simultaneously, conflicts can arise. In Workbench 7.1(13) and later, you can take steps to reduce the possibility of conflicts by dividing the factory configuration file into multiple files. Splitting the configuration file is optional—earlier factory scripts continue to work.

You can extract the following:

  • Data set tags into factory-data-set files
  • Scope tags and measures into factory-scope files

Extracting Data Sets

Each data set can have its own file. Each file represents a domain on its own, and typically, there is no overlap between them. Here is how it works:

In the factory, each data set has its own data-set tag. You can allow each tag to refer to a factory-data-set file, which contains what would otherwise be in the block for that tag. You can migrate one data set at a time to separate files. For example, a configuration file such as:

/config/cfg.factory:

data-sets {
  data-set "Accounts" {
    cbase-input "/data_sources_build/accounts.cbase"
    calc-rule "AMI Account" `value("AMI Diagnoses")> 0 and value("Acute Account")`
    ...
  }
  ...
}

becomes:

/config/cfg.factory:

data-sets {
  data-set "Accounts" file="data-sets/Accounts.factory-data-set"
  ...
}

with the addition of a new file /config/data-sets/Accounts.factory-data-set:

data-set {
  cbase-input "/data_sources_build/accounts.cbase"
  calc-rule "AMI Account" `value("AMI Diagnoses")> 0 and value("Acute Account")`
  ...
}

The rules remain the same. In particular, a link that refers to another data set does so by name, for example:

link "Charges" {
  key "Account ID"
  link-rule "ED Charge" `sum(value("Charge Quantity")) > 0` filter=`value("ED Charges Key")`
  ...
}

This example requires that a "Charges" data set exists in the factory.

The same thing applies to lookup tables and other references.

If the rules are the same, you can use the same data-set file for two different factories. But this has limitations because it only allows you to isolate each data set into its own file. It does not provide a means to maintain a primary version.

Extracting Scopes and Measures

You can separate scopes and scoped measures into factory-scope files. For example, consider a scope block such as:

/config/cfg.factory:

scopes {
  scope "Admissions" data-set="Accounts" {
    filter `value("Date") != null and value("Date") <= current_date()`
    alias "Date" "Admit Date"
    alias "Day of Week" "Admit Day of Week"
  }
  ...
}

The scopes block seems to have a short definition, but there are usually a lot of measures that are associated with it. Those measures are currently defined in the measures tag, inside of measure categories. For example:

/config/cfg.factory:

measures {
  category "Inpatient Volumes" {
    measure "IP Admissions" `count()` filter=`value("Admission")` format="#,#" {
      description "All inpatient admissions excluding Normal Newborns"
      scope "Admissions"
      ...
    }
    ...
  }
  ...
}

Some measures have a scope and some do not. You can move the definitions of the scoped measures into the scope itself, and then move the scope block into its own file; leaving a single line in the measure category to specify the measure's location in the category list. The scripts above becomes:

/config/cfg.factory:

scopes {
  scope "Admissions" file="scopes/Admissions.factory-scope"
  ...
}
measures {
  category "Inpatient Volumes" {
    measure "IP Admissions"
    ...
  }
  ...
}

with a new file:

/config/scopes/Admissions.factory-scope:

scope data-set="Accounts" {
  filter `value("Date") != null and value("Date") <= current_date()`
  alias "Date" "Admit Date"
  alias "Day of Week" "Admit Day of Week"
  measures {
    measure "IP Admissions" `count()` filter=`value("Admission")` format="#,#" {
      description "All inpatient admissions excluding Normal Newborns"
      ...
    }
  }
}

This allows all measures associated with a scope to exist in the same file, regardless of what category they are placed in.

The scope file requires that certain data exists in the factory ("Accounts" in the above example), and all measures must reference rules in that data set. Using this method, scope files are somewhat independent from one another, and different factory instances can share them.

Factory scopes have additional requirements, including:

  • Measure names must be unique within the factory
  • Aliases must reference dimensions in the factory

  • Scopes that do not have the same name as the data set, require a data-set tag, for example: scope data-set="Accounts" {

Attributes that remain in cfg.factory

The following attributes remain in the main factory script:

  • parameters
  • calendars
  • time-ranges
  • lookup-table definitions
  • dimensions
  • dimension-sets
  • measure categories (listing each measure by name)
  • measures that have no scope
  • user-pages-config

When you add a new measure, you must make changes to the top-level script, such as adding the measure to a category. Your edits might conflict with someone else adding a new measure in that script.