Viewpoint API Value Deciders

In the Viewpoint configuration files, there are various places where the XML is expecting a specific data type (like a string) but the XML will accept either hard-coded values, values from a component, or a way to calculate the value. We will refer to these data-type objects as deciders. Each decider has a specified data type (such as boolean, integer, or string). In the XML, the administrator specifies how to get the value in the decider.

• Boolean Deciders
• String Deciders
• Date Deciders
• Integer Deciders
• Double Deciders
• Duration Deciders

Decider vs. Value

Often, concrete values are expected. For example, a <component> element requires a <description> tag with contains the description of an item. For the <description> tag, there must be text describing the component. In this XML element, the description cannot use one of the calculation methods listed below. The description must be set as text in the <description> tag. The <description> element cannot have any child elements. This is what is meant by a concrete value.

However, there are places in the code where a string is expected, but the XML allows the option to put in a concrete value like above, or the value can come from another source like a component or a calculation. This is a decider because the concrete value is determined at run time. This is necessary for when needed values won't be known until run time.

In vpcs.xml, the mshow command being sent to Moab can be customized. The mshow command accepts a -w flag with a gres attribute. The gres attribute should have a name and a quantity. In the XML, specify the name with the <name> element and the amount with the <amount> element. Both of these elements accept hard-coded values or a decider to calculate the value to use. The following example requests 30 units of the generic resource called SAN.

 <generic-resource>
  <name>SAN</name>
  <amount>30</amount>
 </generic-resource>

Here, no matter what the user selects in the component during the create VPC page, 30 units of SAN are always requested. Instead, the user could put how many units of SAN they desire into a textbox called "sanAmountTextbox".

 <generic-resource>
  <name>SAN</name>
  <amount>
   <component id="sanAmountTextbox" />
  </amount>
 </generic-resource>

Now the mshow command requests whatever the user puts into the "sanAmountTextbox" component. If Moab is configured for SAN to be in MB, but users are requesting SAN in GB, you can take whatever the user puts into the textbox, multiply it by 1024, and then send this value to Moab.

 <generic-resource>
  <name>SAN</name>
  <amount>
   <calculate binary-operation="multiply">
    <first>
     <component id="sanAmountTextbox" />
    </first>
    <second>1024</second>
   </calculate>
  </amount>
 </generic-resource>

In this example, a generic resource called SAN is being requested and Viewpoint is instructed to <calculate> the amount. The value in the <first> component is multiplied to the value in the <second> component. If a user requests 50 units of SAN, a request of 51,200 units of SAN is sent to Moab.

Since this example uses multiplication, order doesn't matter. In the case of division or subtraction, verify the values in the <first> and <second> elements are in the proper place.

Calculation operations can be stacked. Continuing with the previous example, if a user wants 51,200 units (50GB) of SAN and wants to use a mirrored array to prevent data loss, they could indicate the number of disks they intend to occupy with their order in a "numDisksTextbox" component.

 <generic-resource>
  <name>SAN</name>
  <amount>
   <calculate binary-operation="multiply">
    <first>
     <calculate binary-operation="multiply">
      <first>
       <component id="sanAmountTextbox" />
      </first>
      <second>1024</second>
     </calculate>
    </first>
    <second>
     <component id="numDisksTextbox" />
    </second>
   </calculate>
  </amount>
 </generic-resource>

As a result, Moab receives a request for 51,200 units (50 GB) of SAN, multiplied by the number of disks the user wants to commit to back up the data.

In the above example, a "multiply" operation is used to determine an integer value. The multiply operation requires two children integer deciders. These integer deciders could in turn require children deciders of their own. Recursion could go on and on until the user uses a component or a hard coded value. This does, however, make the XML much longer and could make it difficult to parse.