Rules: FieldDerivativeTables

SeanR · 21-11-2018 18:18:06

FieldDerivativeTables is a Global Rule, which means if enabled, this rule is applied to all the Fields in the configured Entrypoint.

For FieldDerivativeTables we need to do 2 things:

Configure the Rule
Enable the Rule

NOTE: It is strongly recommended that you use an intelligent XML Editor when editing all X-Layer configuration files.

SXI-approved XML Editors include Oxygen (requires paid license) and Microsoft Visual Studio Tools for Applications 2.0 (included in Visual Studio 2010. Also available by installing the ASP.net package on your machine).

Configuring FielDerivativeTables:

In the configuration, after the </Actions> element, create an <sxi:Tables> element (ignore this step if the configuration already contains an <sxi:Tables> element).
Inside the <sxi:Tables> element, create an <sxi:FieldDerivativeTables> element. (If you are using Oxygen to edit the config file, the rest of the required fields would have auto-populated). Remember to close the tag with </sxi:FieldDerivativeTables> if your XML Editor has not done so already.

Create the following inside <sxi:FieldDerivativeTables>, if your XML Editor have not done so already:

<sxi:Match reference="">
	<sxi:InputField name="">
		<sxi:InputValue></sxi:InputValue>
	</sxi:InputField>
</sxi:Match>

The above simply enables us to first identify which fields in the transaction we want to match on. For example, if we have the following:

<sxi:Match reference="Reference1">
	<sxi:InputField name="Requestor">
		<sxi:InputValue>Harry</sxi:InputValue>
	</sxi:InputField>
</sxi:Match>

"Match reference" is the "ID" of this specific match we are configuring. You can use any value here. We will be referencing it later.
"InputField name" is the ELEMENT or TAG NAME in the transaction that will contain the value we want to match on. Example: the TAG NAME of <User>Jane Doe</User> is "User".

"InputValue" is the value inside the above element to match. If multiple "InputValues" are configured then the rule will try to match any one of them. Example:

<sxi:Match reference="Reference1">
	<sxi:InputField name="Requestor">
		<sxi:InputValue>Harry</sxi:InputValue>
		<sxi:InputValue>Sally</sxi:InputValue>
	</sxi:InputField>
</sxi:Match>

We can also match as many fields as needed. For example:

<sxi:Match reference="Reference1">
	<sxi:InputField name="Requestor">
		<sxi:InputValue>Harry</sxi:InputValue>
		<sxi:InputValue>Sally</sxi:InputValue>
	</sxi:InputField>
	<sxi:InputField name="Company">
		<sxi:InputValue>ABC</sxi:InputValue>
	</sxi:InputField>
</sxi:Match>

To summarize the the above configuration: We have a Match reference called "Reference1", which encapsulates the following conditions: IF the transaction contains an element name called "Requestor" with a value OF EITHER "Harry" or "Sally", AND an element name called "Company" which contains a value called "ABC", then we have a match!

You can create as many Match references as needed. Keep in mind that each Match Reference must have a unique ID (example: Reference1, Reference2, Reference3, etc.). Below is an example containing 2 Match references:

<sxi:Match reference="Reference1">
	<sxi:InputField name="Requestor">
		<sxi:InputValue>Harry</sxi:InputValue>
		<sxi:InputValue>Sally</sxi:InputValue>
	</sxi:InputField>
	<sxi:InputField name="Company">
		<sxi:InputValue>ABC</sxi:InputValue>
	</sxi:InputField>
</sxi:Match>

<sxi:Match reference="Reference2">
	<sxi:InputField name="Requestor">
		<sxi:InputValue>Peter</sxi:InputValue>
	</sxi:InputField>
	<sxi:InputField name="Company">
		<sxi:InputValue>DEF</sxi:InputValue>
	</sxi:InputField>
</sxi:Match>

Now we need to tell the rule which modifications must be made if we have a match. Again, if your XML Editor has not already done so, create an element called <sxi:OutputReferences> after the last </sxi:Match> element. Remember to close the tag with </sxi:OutputReferences>.

Inside </sxi:OutputReferences>, create the following (only if it did not auto-populate already):

<sxi:Reference name="">
	<sxi:Fieldname name="">
		<sxi:Output></sxi:Output>
	</sxi:Fieldname>
</sxi:Reference>

In the "Reference name" field, put in the NAME of the "Match Reference" we used earlier. In our example this would be "Reference1". Example:
```
<sxi:Reference name="Reference1">
	<sxi:Fieldname name="Department">
		<sxi:Output>Sales</sxi:Output>
	</sxi:Fieldname>
</sxi:Reference>
```
"Fieldname name" is the NAME of a newly created OUTPUT Field we want to add to our transaction. In the above example we are creating an element name of <Department>.
"Output" is VALUE we want to assign to this new element. In our example this would mean that we have just created an element <Department> with a value of "Sales" ie. <Department>Sales</Department>.

You can assign multiple Fields and values per match, like below:

 
<sxi:Reference name="Reference1">
	<sxi:Fieldname name="Department">
		<sxi:Output>Sales</sxi:Output>
	</sxi:Fieldname>
	<sxi:Fieldname name="Site">
		<sxi:Output>Head Office</sxi:Output>
	</sxi:Fieldname>
	<sxi:Fieldname name="City">
		<sxi:Output inputfield="yes">Location</sxi:Output>
	</sxi:Fieldname>
</sxi:Reference>

Look at the Output of the last field: <sxi:Output inputfield="yes">Location</sxi:Output>. inputfield="yes" means that we don't want to use a hard-coded value as output, but we want the rule to fetch the value of a specific element in the transaction instead. In the above example we are telling the rule to create a new element called <City>, and assigning the value of an existing element in the transaction called <Location> to <City>.
It is also possible to have multiple <sxi:Reference> elements, which should always match the amount of <sxi:Match reference> elements.

Enabling FieldDerivativeTables:

Now that we have configured the rule, we need to tell it when it should run. This is configured at Entrypoint level. In other words, it should be enabled for each Entrypoint where we want to run this rule.

Identify the Entrypoint(s) where the FieldDerivativeTables rule should run. Then, directly under the <sxi:EntryPoint name="..." source="..."> element, add the following:
```
<sxi:GlobalRules>
	<sxi:FieldDerivatives/>
</sxi:GlobalRules>
```
We can also specify that the FieldDerivativeTables rule runs BEFORE any local rules (which apply only to individual fields) are processed:
```
<sxi:GlobalRules>
	<sxi:FieldDerivatives first="yes"></sxi:FieldDerivatives>
</sxi:GlobalRules>
```

Below is an example Entrypoint configuration with an enabled FieldDerivateTables rule:

<sxi:EntryPoint name="CreateIncident" source="d_serviceprovider_sd">
	<sxi:GlobalRules>
		<sxi:FieldDerivatives first="yes"></sxi:FieldDerivatives>
	</sxi:GlobalRules>
	<sxi:Fields>
		<sxi:Field name="callnum">
			<sxi:OutputField>TicketNumber</sxi:OutputField>
		</sxi:Field>
		<sxi:Field name="Assigned_Group">
			<sxi:Rules>
				<sxi:Default>Support</sxi:Default>
			</sxi:Rules>
			<sxi:OutputField>Assigned_Group</sxi:OutputField>
		</sxi:Field>
		<sxi:Field name="Name">
			<sxi:OutputField>Name</sxi:OutputField>
		</sxi:Field>
		<sxi:Field name="Description">
			<sxi:OutputField>Description</sxi:OutputField>
		</sxi:Field>
		<sxi:Field name="State">
			<sxi:Rules>
				<sxi:Default>Assigned</sxi:Default>
			</sxi:Rules>
			<sxi:OutputField>State</sxi:OutputField>
		</sxi:Field>
	</sxi:Fields>
</sxi:EntryPoint>

SXI Forum

#1 21-11-2018 18:18:06