0
Not a bug

Join with Sliding Window with Most Relevant doesn't match record with NULL end date

Adrian Corston 4 years ago in UNIFYBroker Service updated by Matthew Davis (Technical Product Manager) 3 years ago 6

UNIFYBroker v5.3.2 with Chris21.

Chris21 Person adapter is configured with a Join transformation to a Chris21 placement connector with a Sliding Window and type Relevant.  A placement with a start date in the past and a NULL end date is not being selected (a NULL end date means ongoing placement, with no scheduled end date).  Instead, the most recent placement with a non-NULL end date is selected.

Here is the placement data:

Image 5870

Here is the configuration:

Image 5871

The transformed adapter data shows an incorrect posstart and posend (and all other selected attributes):

Image 5872

This problem did not occur in Identity Broker v4.

It may also be relevant to note that the 'First' or 'Priority Selection' radio box does not appear for the Relevant type.  It used to appear for this transform and type in Identity Broker v4.

Answer

Answer

Hi Beau, sorry I thought I'd already responded to this.  The problem was just a handful of records and Generate Changes cleared it.  Please close this ticket.

Under review

Hi Adrian

Not able to replicate this behaviour. Can you provide your extensibility config files?

Everything seems fine with your config, looks the same as mine. Can you confirm the following?

  1. The incorrect result persists after both main and relational connectors are imported
  2. The incorrect result persists running Operations > Generate Changes on the adapter
  3. What patches, if any, you have installed in the Service and Service\Patches directories.
  4. Does this occur only with the one person record, or are there others? If this is the only null-ending position record, do you have the ability to create another for a different person to test?

After a Generate Changes the adapter data has now updated correctly.

Is periodic execution of Generate Changes recommended to keep data up to date and correct?  This is a relatively new build and hasn't seen much activity other than an initial data load.

No, that's not needed, as the exact same process naturally occurs when the any of the related connectors import.

How long ago was the initial import performed? Would it have been at a time that fell within the 1st July - 16th Aug time frame, meaning at some point the invalid join result was correct?
Answer

Hi Beau, sorry I thought I'd already responded to this.  The problem was just a handful of records and Generate Changes cleared it.  Please close this ticket.