When using XOG to update a custom attribute lookup value where there are similar values, the XOG is performing a close match, not an exact match. For example, if a Lookup list has two close values such as ABC1234 and ABC12345. XOG will use a 'Like' operator (%) in the query and will find ABC12345 value to update the field, when the XOG file has the ABC1234 value specified.
Steps to Reproduce:
1. A lookup is defined on the Project object which points to a "client" table
3. In the XOG, update the project as follows:
<?xml version="1.0" encoding="UTF-8"?>
<NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_read.xsd">
<Header action="write" externalSource="NIKU" objectType="project" version="15.9.2.910">
<Projects>
<Project name="Client_ market_ test1_March23rd_2022" projectID="PRJ123456">
<CustomInformation>
<ColumnValue name="eu_client_name">CLN-000100<ColumnValue>
</CustomInformation>
<Project>
</Projects>
<NikuDataBus>
3. The project is updated successfully but with the wrong lookup value. The project was updated with 'CLN-0001000' when it should have been 'CLN-000100'.
Expected Results: The XOG update should perform an 'exact match'.
Actual Results: The XOG update is the wrong value because it is performing a 'Like' operator for a close match.
Release : 16.0.1, 16.0.2
Clarity XOG is adding a wild card to the search "CLN-000100*" and coming back with the first row returned instead of an exact match.
DE64713, fixed in 16.0.3 and 16.0.2.1
Workaround: Set the Lookup definition for the Auto Suggest 'Search' configuration to use the 'code' field. The XOG action will then use the 'exact' match logic.