Skip to content

Variables and Conditions

Within each DataSet you can define free variables which can then be used in expressions for filters. In this way, it is possible to further filter dependent data before it is provided in the document.

In this example, two account and territory variables defined are used in the filter of the subordinate DataSet.The variables are defined without "@"; in the text, the @ symbol must be pre-assigned to each variable.

Conditions are often used in conjunction with variables. Conditions allow the "conditional" execution of subordinate DataSets, e.g. if the variables are not empty. DataSets are generally only executed if all conditions contained in the DataSet are true. This differentiates them from filters that are applied during the execution of the DataSets.

In the following example, the execution of the LinkedFetchXmlDataSet is dependent on whether the account and territory variables are defined. They are defined when the associated nodes accountid and territoryid exist in the XML output and this is the case when the two data fields of the same name are not empty:

<i18n:DefaultDataSet>
    <i18n:Variable Name="Account" Src="accountid"/>
    <i18n:Variable Name="Address1_City" Src="address1_city"/>

    <i18n:LinkedFetchXmlDataSet ItemName="Contact" MultipleItems="true">
      <i18n:Condition Variable="Account" Operator="NotNull" />
      <i18n:Condition Variable="Address1_City" Operator="NotNull" />

      <i18n:FetchXml>
        <fetch>
          <entity name="contact">
            <attribute name="firstname" />
            <attribute name="lastname" />
            <filter>
                <condition attribute="parentcustomerid" operator="eq" value="@Account" />
                <condition attribute="address1_city" operator="eq" value="@Address1_City" />
            </filter>
          </entity>
        </fetch>
      </i18n:FetchXml>

    </i18n:LinkedFetchXmlDataSet>
</i18n:DefaultDataSet>

Variables are only valid inside their defining DataSet and all subordinate LinkedSataSets and LinkedFetchXmlDataSets.

System-wide Variables

The following variables are available automatically before the DataSets are executed:

  • @organizationname: The unique identifier of the CRM organization with the region prefix
  • @crmurl: The base url of the Dynamics environment (without /api)
  • @now: The current datetime in UTC
  • @objecttype: The type of the object for which the document is created
  • @objectid: The primary key of the object for which the document is created
  • @parentid: Corresponds to the primary key (FromAttribute) of the parent DataSet when nesting
  • @userid: The primary key of the user who creates the document
  • @datasourceid: The primary key of the data source
  • @datasourcename: the name of the data source
  • @templateid: The primary key of the template
  • @templatename: The name of the template
  • @templatelanguage: The language code (LCID) selected within the template
  • @templatefilename: The filename of the template file uploaded to the template
  • @engineid: The primary key of the engine
  • @enginename: The name of the engine
  • @formattinglcid: The LCID used for the current user
  • @dateseparator: The date seperator of the current user
  • @dateformat: The datwe format of the current user
  • @timeformat: The time format of the current user

Application of Variables

Example 1: Retrieving data from the current template

All the data in the template are loaded and made available in the template node:

<i18n:DataSet Entity='aw_officetemplate' ItemName='Template'>
  <i18n:Filter>
    <filter>
      <condition attribute='aw_officetemplateid' operator='eq' value='@templateid' />
    </filter>
  </i18n:Filter>
</i18n:DataSet>

Example 2: Retrieve user data

In the following example, the data of the calling user should be loaded. Assuming you want to create a FetchXML statement using the Advanced Search, you get the following code:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="systemuser">
  <attribute name="fullname" />
    <filter type="and">
      <condition attribute="systemuserid" operator="eq-userid" />
    </filter>
  </entity>
</fetch>

However, they can not be copied into their FetchXmlDataSet because the operator "eq-userid" can only be interpreted by the CRM system itself. These filters have to be modified by hand. The ID of the current user is available in the system-wide @userid variable so that they can filter with it:

<i18n:FetchXmlDataSet ItemName="User">
  <i18n:FetchXml>
    <fetch>
      <entity name="systemuser">
        <attribute name="fullname" />
          <filter>
            <condition attribute="systemuserid" operator="eq" value="@userid" />
          </filter>
      </entity>
    </fetch>
  </i18n:FetchXml>
</i18n:FetchXmlDataSet>

Example 3: Relation to the parent record

The situation where the primary key of the parent record is used via the @parentid variable for further filtering of subordinate DataSets is also met very often. Please note that the variable @parentid is only available if the primary key of the parent data record is specified in the FromAttribute of the LinkedFetchXmlDataSet.

<i18n:DataSet Entity='account' ItemName='Account'>
  <i18n:Columns>
    <i18n:Column>name</i18n:Column>
    <i18n:Column>accountnumber</i18n:Column>
  </i18n:Columns>
  <i18n:LinkedFetchXmlDataSet ItemName="Contact" FromAttribute="accountid" MultipleItems="true">
     <i18n:FetchXml>
        <fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
           <entity name="contact">
              <attribute name="fullname" />
              <filter type="and">
                <condition attribute="parentcustomerid" operator="eq" value="@parentid" />
              </filter>
           </entity>
        </fetch>
     </i18n:FetchXml>
  </i18n:LinkedFetchXmlDataSet>
</i18n:DataSet>